- sr-users - kamailio.org

Re: [Kamailio-Users] Problem With Carrierroute on Solaris
by Ali Jawad 21 Jan '09

21 Jan '09

It worked finally, As per hint I did change endif DEFS+=$(CONFUSEDEFS) LIBS=$(CONFUSELIBS) To endif CONFUSEDEFS=-I$(LOCALBASE)/include -I/usr/local/include -I/opt/include -I/usr/sfw/include CONFUSELIBS=-L$(LOCALBASE)/lib -L/usr/local/lib -L/usr/sfw/lib -L/opt/lib -lconfuse DEFS+=$(CONFUSEDEFS) LIBS=$(CONFUSELIBS) Now I got an error that Jan 21 14:36:24 [24863] INFO:carrierroute:bind_data_loader: use file as configuration sourceJan 21 14:36:24 [24863] ERROR:carrierroute:bind_data_loader: can't stat config file But this is a totally different story :), let me hit the carrierroute documentation. Thanks A million -----Original Message----- From: Henning Westerholt [mailto:henning.westerholt@1und1.de] Sent: 2009-01-21 15:32 To: Ali Jawad Subject: Re: [Kamailio-Users] Problem With Carrierroute on Solaris On Wednesday 21 January 2009, you wrote: > At current it is > > /opt/lib -lconfuse <-- note the L > > should I make that > > /opt/lib -confuse -lgcc > > or > > /opt/lib -lconfuse -lgcc <- double L The last one, with two 'l' is correct. The '-l' tells the compiler that this is a linker configuration, after the l comes the library name. '-L' is a library location.

1 0

[Kamailio-Users] Job description
by laurent schweizer 21 Jan '09

21 Jan '09

JOB TITLE: VOIP SOFTWARE DEVELOPER LOCATION: Zurich/Switzerland JOB TYPE: Full time COMPANY: Peoplefone AG is a Pan-European VoIP provider present in 4 countries and headquartered in Zurich/Switzerland ( www.peoplefone.com). JOB DESCRIPTION: - Manage together with CEO/CTO the geographical expansion on IT level - Develop and maintain the VoIP Platform (OPENSER, billing software,…) - Create new VoIP features for the clients - Ensure excellent quality of VoIP service and appropriate security level - Supervise interactions with webmasters for the website development - Provide technicians and customer service of affiliates with technical support REQUIREMENTS: - Graduation from college or university with a Bachelor's degree(preferably IT) - Practical knowledge of C, C++, PHP and JAVA - Practical knowledge of database like Mysql and Postgresql - Linux experience - Experience with tools for Network analysis like Ethereal - VoIP knowledge with experience on OPENSER/ASTERISK platform - Fluency in English - Ability to interact with individuals and groups at all levels - Detail oriented and analytical - Strong verbal and written communication skills +41 44 553 20 01 (Office CH) +43 1 266 00 50 (Office A) +48 22 311 78 35 (Offfice PL) Alfred Escher-Strasse 26 Pottendorfer Str. 25-27 Al. Jerozolimskie 179 8002 Zurich/Switzerland 1120 Wien/Austria 02-222 Warsaw/Poland www.peoplefone.ch www.peoplefone.at * www.plfon.pl*

1 0

[Kamailio-Users] SEMS 1.1.0 released
by Stefan Sayer 20 Jan '09

20 Jan '09

Hello, Version 1.1.0 of SEMS, the SIP Express Media Server, has been released. SEMS is a free, high performance, extensible media and application server for SIP (RFC3261) based VoIP services. New in version 1.1 is: * DSM state machine scripting (it's cool!) * an (experimental) ISDN gateway module * binrpc: MT (SER->) and connection pool (->SER) * MT xmlrpc server * controlled server shutdown * improved logging * g722 in 8khz compat mode * out of dialog request handling for modules & dialogs without sessions * audio file autorewind, AmAudio mixing * SIP and media IP separately configurable * UID/DID support for voicemail/-box/annrecorder * and quite some bugs and mem leaks fixed, documentation, etc. You can get the sources from ftp://ftp.iptel.org/pub/sems/sems-1.1.0.tar.gz and find documentation and packages at ftp://ftp.iptel.org/pub/sems/1.1/1.1.0/ and a debian repository (etch/lenny) at deb http://ftp.iptel.org/pub/sems/debian etch free deb-src http://ftp.iptel.org/pub/sems/debian etch free Further documentation, links to lists, tracker etc is available at the project's homepage: http://iptel.org/sems/ I would like to thank for all contributions and patches, this time from Stefan Sayer, Raphael Coeffic, Grzegorz Stanislawski, Bogdan Pintea, Greger Teigre, Rui Jin Zheng, Alfred E Heggestad, Juha Heinanen, Peter Lemenkov, Peter Loeppky, Robert Szokovacs, Jeremy A, Alex Gradinar Apologies if you receive multiple copies of this message. Best Regards Stefan Sayer -- Stefan Sayer VoIP services stefan.sayer(a)iptego.com www.iptego.com IPTEGO GmbH Am Borsigturm 40 13507 Berlin Germany Amtsgericht Charlottenburg, HRB 101010 Geschaeftsfuehrer: Alexander Hoffmann

2 2

[Kamailio-Users] URIs in "P-Asserted-Identity" headers
by Alex R.S.M 20 Jan '09

20 Jan '09

Hi, How can I extract the URIs in "P-Asserted-Identity" when there are multiple "P-Asserted-Identity" headers. Variable $ai return the URI in the first "P-Asserted-Identity" header. Thanks, Alex _________________________________________________________________ Windows Live™: Keep your life in sync. http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t1_allup_howitworks_012…

5 11

[Kamailio-Users] Problem With Carrierroute on Solaris
by Ali Jawad 20 Jan '09

20 Jan '09

Hi All I did remove carrierroute from the excluded modules and I did recompile, all went smooth however when I try to run the server with the module loaded I get this error : fatal: relocation error: file carrierroute.so: symbol cfg_init: referenced symbol not found echo $LD_LIBRARY_PATH /opt/csw/mysql5/lib/mysql/:/opt/csw/lib/:/opt/csw/include/:/opt/csw/incl ude/openssl/:/usr/local/lib/ find /usr/ -name "*confuse*" /usr/local/include/confuse.h /usr/local/lib/libconfuse.a /usr/local/lib/libconfuse.la /usr/local/lib/libconfuse.so /usr/local/lib/libconfuse.so.0 /usr/local/lib/libconfuse.so.0.0.0 Please advice.

2 4

[Kamailio-Users] ERROR:tm:t_forward_nonack: no branch for forwarding
by Juan Asencio 20 Jan '09

20 Jan '09

Hi list, Has anyone a suggestion to solve this error or where it might come from? I'm using carrierroute module to route calls through to different domains, but I can't make it work properly. [root@localhost kamailio]# Jan 20 12:05:52 localhost /sbin/kamailio[24686]: INFO:carrierroute:cr_do_route: uri 123456 was rewritten to sip:123456@200.100.200.100 Jan 20 12:05:52 localhost /sbin/kamailio[24686]: ERROR:tm:t_forward_nonack: no branch for forwarding Jan 20 12:05:52 localhost /sbin/kamailio[24686]: ERROR:tm:w_t_relay: t_forward_nonack failed Jan 20 12:05:52 localhost /sbin/kamailio[24680]: CRITICAL:tm:t_should_relay_response: pick_branch failed (lowest==-1) for code 484 Thanks in advance. Juan.-

2 1

[Kamailio-Users] new comparison functions in config
by Daniel-Constantin Mierla 19 Jan '09

19 Jan '09

Hello, following discussions on the mailing lists and tracker related to string and URI/AoR comparison, textops and siputils introduce new dedicated functions: - cmp_str(str1, str2) - compare two strings case sensitive - cmp_istr(str1, str2) - compare two strings case insensitive - cmp_uri(str1, str2) - compare two URIs as per RFC3261(up to parameters comparison rules) - cmp_aor(str1, str2) - compare two address of records http://kamailio.org/docs/modules/devel/textops.html http://kamailio.org/docs/modules/devel/siputils.html Just to refresh, the string comparison using config operators (==, <=, ...) are case insensitive (== is equivalent to cmp_istr(...)). Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

1 0

[Kamailio-Users] Vrrp/Linux-HA, paid consulting opportunity
by sergejf 19 Jan '09

19 Jan '09

Hello, I hope this is the right forum to post a request for consulting services. We have a requirement for setting up a HA OpenSIPS 1.4.2 installation with a primary (active) and secondary (failover) server running CentOS 5.x. SIP messages from the active server must come from a virtual IP address and carrier gateways receiving our call traffic must remain oblivious to any server failure. Failover must occur in < 5 seconds. We would like to see a simple solution based on open source components like vrrp or Linux-HA, including the SIP heartbeat mechanism and failover per se, as well as the recovery process once the primary server recovers from the failure causes. The work will be done in conjunction with our Linux Administrator and IP Telephony Engineer and must be documented, at least in a basic fashion. Failover testing under load will be performed prior to project acceptance. If you are an expert in OpenSER HA implementations and are interested to help us, please respond via this forum or directly to my e-mail address, serge A T elasticall D O T com. Thanks in advance. Best Regards, Serge -- View this message in context: http://www.nabble.com/Vrrp-Linux-HA%2C-paid-consulting-opportunity-tp215460… Sent from the OpenSER Users Mailing List mailing list archive at Nabble.com.

3 2

[Kamailio-Users] t_check_trans() fails
by Alex R.S.M 19 Jan '09

19 Jan '09

Hi, What might be the cause that t_check_trans() function fails and ACK message is not being routed? This is a simple SIP to SIP call. if ( is_method("ACK") ) { if ( t_check_trans() ) { # non loose-route, but stateful ACK; must be an ACK after a 487 or e.g. 404 from upstream server t_relay(); exit; } else { # ACK without matching transaction ... ignore and discard.\n"); exit; } } _________________________________________________________________ Windows Live™ Hotmail®: Chat. Store. Share. Do more with mail. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_hm_justgotbetter_explor…

2 1

[Kamailio-Users] Run Server in background with maximum debug to log file
by Ali Jawad 19 Jan '09

19 Jan '09

Hi I am running the server with debug=9 and fork=yes and log standard output = yes. when I do that I can see a lot of debug info and sip packets in the standard output however the log file does show only some notices and xlog entries. So when I close putty and get back later or a few days later I have to kill and restart openser to see debug info as the log file is not showing maximum debug levels unlike the standard output. Please advice, the goal I want to reach is to see maximum loggin in a file so I can check it out without having to restart the server. Thanks

2 1

[Serusers] [somewhat OT] seeking ideas/input for my thesis
by sp4rc 19 Jan '09

19 Jan '09

Hello VoIP guys Sorry for being somewhat off-topic. At the moment I am studying informatics in the seventh semester and I need to start thinking about my thesis. As I am very interested in VoIP technologies I thought about picking this as my main topic. So far I have only little experience in this area. I have been fiddling around with siproxd and pfSense and have red the one or the other packet dump containing SIP and RTP traffic, had a look into codecs, STUN, etc... but very cursorily, and that's the reason why I am quite unsure on which track to go. I think I am quite familiar with many network protocols and devices... so here comes the question of the questions: What would be a great project for my thesis to work on in the VoIP field? What are topics that still need special development? The time frame should be around 300 hours but don't take this value too seriously... Any ideas are welcome! /sp4rc

1 0

[Kamailio-Users] SNMPStats per request statistics, is that possible?
by Noel R. Morais 19 Jan '09

19 Jan '09

Hi Guys, Is possible to have per request statistics from the SNMPStats module? What I mean is if I can know how many INVITES, REGISTERS, SUBSCRIBERS, NOTIFIES and so on were processed by kamailio. is that possible? Cheers, Noel

2 1

[Kamailio-Users] new feature: run route blocks on timer
by Daniel-Constantin Mierla 17 Jan '09

17 Jan '09

Hello, a new module was committed in trunk, to be released as 1.5.0 - the plan at: http://www.kamailio.org/dokuwiki/doku.php/features:new-in-1.5.x The rtimer module allows to execute route block on timer. It can create new processes that will do the timer execution of the routes or use existing timer. There can be multiple timers and each timer can execute multiple route blocks.See readme at: http://kamailio.org/docs/modules/devel/rtimer.html Such features is useful if you want to do periodic jobs in your service 1) clean a database were you store temporary data - e.g., delete entries older than 2 hours modparam("rtimer", "timer", "name=ta;interval=10;mode=1;") modparam("rtimer", "exec", "timer=ta;route=8") route[8] { sql_query("ca", "delete from tmp where timeval<$TS-3600","ra"); } 2) save statistics in database so you can build graph, etc... http://www.kamailio.org/dokuwiki/doku.php/pseudovariables:devel#statistics route[8] { sql_query("ca", "insert into kamailio_stats values ($stat(...), ...)","ra"); } 3) Along with another pretty new feature - sending sip requests from config file: http://lists.kamailio.org/pipermail/users/2009-January/021426.html you can implement keep-alive/syncronization mechanisms within your farm of sip routers. Any other ideas? Let's see the best one for using the new stuff from uac and the rtimer module... Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

3 5

[Kamailio-Users] new features in htable module
by Elena-Ramona Modroiu 16 Jan '09

16 Jan '09

Hi, htable module has been enhanced with couple of features that give more flexibility in working as config file cache system. - auto-expire - to each value stored in hash table can be assigned an expire value. If no update was done in that time interval, the value will be automatically removed. One new pseudo-variable class has been added to manage the expire values: $shtex(htable=>key) - it can be used to get/set the time-out interval. To get this feature on, the hash table definition must include autoexpire attribute greater than 0. - sht_rm_name_re(htable=>regexp) - delete from hash table all entries that match the name against regexp - sht_rm_value_re(htable=>regexp) - delete from hash table all entries that match the value (string) against regexp - reload the content of a hash table from database at runtime upon MI command. The hash table definition must include the database table name, then you can issue: 'kamctl fifo sht_reload htname' to reload the hash table with name 'htname'. Check the documentation at: http://kamailio.org/docs/modules/devel/htable.html Regards, Ramona

2 3

[Kamailio-Users] Registered user
by michel freiha 16 Jan '09

16 Jan '09

Dear All, I need to ask please about which function should I use in order to check while making a call if the user who is dialing the number is making the call from a registered account or not? Regards

5 17

[Kamailio-Users] new feature: send sip requests from config file
by Daniel-Constantin Mierla 16 Jan '09

16 Jan '09

Hello, uac module provides a new function that allow sending sip requests from configuration file: - uac_send_req() http://kamailio.org/docs/modules/devel/uac.html#id2467912 It opens the door for a new bunch of things you can do now. I can think of now: 1) send IM alerts on special events route { $uac_req(method)="MESSAGE"; $uac_req(ruri)="sip:alert@kamailio.org"; $uac_req(furi)="sip:server@kamailio.org"; $uac_req(hdrs)="Content-Type: text/plain\r\n"; $uac_req(body)="SIP request from:" + $si + ":" + $sp; uac_send_req(); } 2) turn lamps on for some sip phones on some events - e.g., snom: http://wiki.snom.com/Features/LED_Remote_Control 3) talk server-to-server - here one example can be building a platform with a central server for accounting Accounting is done at 200ok. So each routing server will build a csv list (time,callid, from tag, to tag, invite from uri, invite r-uri): onreply_route[1] { if(status!="200") return; $uac_req(method)="ACCOUNTING"; $uac_req(ruri)="sip:store@accounting.kamailio.org"; $uac_req(furi)="sip:server@server1.kamailio.org"; $uac_req(hdrs)="Content-Type: text/accounting-csv\r\n"; pv_printf($uac_req(body), "$TS,$ci,$ft,$tt,$T_req($fu),$T_req($ru)"); uac_send_req(); } note that $T_req() is given by tm module, also with Kamailio trunk: http://www.kamailio.org/dokuwiki/doku.php/pseudovariables:devel#tm_module_p… The accounting server: route{ # you should check the source IP also if(method=="ACCOUNTING" && $rU="store") { sql_query("ca", "insert into accounting(timeval,callid,ftag,ttag,src,dst) values ('$(rb{s.select,0,,})','$(rb{s.select,1,,})', ...)", "ra"); send_reply("200", "Stored"); } } ... and put your imagination work ... there are plenty of new and cute features you can add on your service with this functionality ... Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

3 4

[Kamailio-Users] TCP ZeroWindow and TCP Window Full
by Gawith 16 Jan '09

16 Jan '09

Hi, I see enormous TCP problems on my systems. All of a sudden, a perfectly working TCP session uses ZeroWindow packets, later I see TCP Full Window packets and finally the peer resets the connection. In the logs I see a lot of "core:handle_io: empty fd map" messages. Has anyone experienced similar problems? Regards.

2 3

[Kamailio-Users] SIP Digest Access Authentication RELAY survey
by Victor Pascual Ávila 16 Jan '09

16 Jan '09

Hi, excuse me if this message is not directly related to Kamailio. I'm just wondering if folks could share with me if (and how) they have prevented the "SIP Digest Access Authentication RELAY" in their networks (and what worked for them or not). NAT boxes reduce dramatically the scenarios for a successful attack. Otherwise, some might be mitigating the attack by means of forcing UAs to use outbound proxies while others might be reducing the attack incentives by means of message integrity. Any comment would be appreciated, -- Victor Pascual Ávila

5 9

[Kamailio-Users] WeSIP sans Tomcat.
by Alex Balashov 16 Jan '09

16 Jan '09

Will WeSIP run in Jetty? -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (678) 237-1775

4 4

Re: [Kamailio-Users] serMyAdmin Install
by Flavio Goncalves 15 Jan '09

15 Jan '09

Please, post this questions also in the serMyAdmin forum www.sermyadmin.org. I think the main developer Leonardo is not a subscriber of the list. Flavio

1 0

Re: [Kamailio-Users] serMyAdmin
by Flavio Goncalves 15 Jan '09

15 Jan '09

Date: Thu, 15 Jan 2009 17:20:29 +0100 (CET) From: "Juan Asencio" <juan(a)asencio.dk> Subject: [Kamailio-Users] serMyAdmin To: "users" <users(a)lists.kamailio.org> Message-ID: <d077ccb2f33e62d0814f1b519fb7ebfb.squirrel(a)webmail1.b-one.net> Content-Type: text/plain;charset=iso-8859-1 Hi list, I would like to ask if serMyAdmin works with Kamailio and if it does what changes would be necessary to make it work?Cheers, Juan.->Yes it works. Just create a symbolic link. /etc/opensips/ln -s opensipsctl kamctl. Sorry about this. In the next wersion we are planning to provide a configuration fileto avoid this ugly solution. We want to support as many versions as feasible. Kamailio, OpenSIPs and OpenSER.Check www.sermyadmin.org for the latest version for OpenSER. Regards, Flavio E. Goncalves

1 0

[Kamailio-Users] sermyadmin install
by TCB 15 Jan '09

15 Jan '09

I hope this is the right list, i'm trying to run latest sermyadmin against a remote mysql DB. I get error of this nature. Last packet sent to the server was 0 ms ago. at java.security.AccessController.doPrivileged(Native Method) ... 22 more Caused by: org.springframework.jdbc.support.MetaDataAccessException: Could not get Connection for extracting meta data; nested exception is org.springframework.jdbc.CannotGetJdbcConnectionException: Could not get JDBC Connection; nested exception is com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure -- TC

3 2

[Kamailio-Users] [Fwd: RE: new developer: Inaki Baz Castillo]
by Daniel-Constantin Mierla 15 Jan '09

15 Jan '09

... probably was meant here ... -------- Original Message -------- Subject: RE: [Kamailio-Users] new developer: Inaki Baz Castillo Date: Thu, 15 Jan 2009 14:43:42 -0500 From: David A Céspedes <ingdavidcespedes(a)cable.net.co> To: 'Daniel-Constantin Mierla' <miconda(a)gmail.com> References: <496E1A35.9050605(a)gmail.com> Congratulations to Iñaki. He has help me a lot in my bachelor thesis about SIPconnect. Great add to the developers team. David Cespedes -----Mensaje original----- De: users-bounces(a)lists.kamailio.org [mailto:users-bounces@lists.kamailio.org] En nombre de Daniel-Constantin Mierla Enviado el: Miércoles, 14 de Enero de 2009 12:01 p.m. Para: kamailio; devel Asunto: [Kamailio-Users] new developer: Inaki Baz Castillo Hello, here it is the proper welcome of Iñaki Baz Castillo as developer -- SourceForge id: ibc_sf. Log time community member and active contributor with troubleshooting, patches and support emails, Inaki committed his first module today (announcements sent hours ago): http://lists.kamailio.org/pipermail/devel/2009-January/017544.html He has an extensive knowledge of SIP and he is know as PITA for those writing confusing RFCs. Thanks for your work and looking forward to collaborating in the project. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com _______________________________________________ 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 -- Daniel-Constantin Mierla http://www.asipto.com

1 0

[Kamailio-Users] disable simultaneous register
by Luis Guaman 15 Jan '09

15 Jan '09

Hi all, Does anybody let me know how to disable simultaneous registers, using the same user login/password in two or more different machines? thanks in advance Luis Guaman Interlancompu

3 10

[Kamailio-Users] Running the server on 64 bit platform
by Ali Jawad 15 Jan '09

15 Jan '09

If I do download the latest version of the server and compile from source, I do have a sparc system with 64 bit. Will the server software run on 64bit ? With Regards Ali Jawad System Administrator Splendor Telecom (www.splendor.net <outbind://41/www.splendor.net> ) Beirut, Lebanon Phone: +961 1 373725 Fax: + 961 1 375554

2 1

[Kamailio-Users] CDRTool
by Brian Chamberlain 15 Jan '09

15 Jan '09

Hi All, Using CDRTool 6.7.1 with Kamailio 1.4.1, have the rating engine running now fine. Doing my accounting using Freeradius and the CDR's are showing up fine in CDRtool. I am starting to work on the rates and destinations etc.. One issue I may have, one of my providers makes me put *1001* in front of the number I am dialling and then the local code, not the international one.. How will I normalise this *1001* so that CDRTool will just read in the prefix? Also can anyone point me in the direction of good documentation for the rating engine? The rating.txt is a bit vague at best. TIA. Brian

1 0

Re: [Kamailio-Users] debian packages not found
by Henning Westerholt 15 Jan '09

15 Jan '09

On Thursday 15 January 2009, Amit Agarwal wrote: > Hello Henning, > Thanks, > But It was also my mistake - I didnt go through the document properly. > I managed to download the packages for debian from > http://www.kamailio.org/pub/kamailio/latest-1.4.x/packages/debian/etch/ Hi Amit, ok. Please keep in mind that this is not the latest release of the stable branch 1.4, so if you want to use kamailio in production, i'd suggest to use 1.4.3. It contains many bug fixes over the package you use now. Cheers, Henning

1 0

[Kamailio-Users] new: simplified compile options system
by Daniel-Constantin Mierla 15 Jan '09

15 Jan '09

Hello, trunk includes now an easier system to give the compile options. So far, changing the size of private memory, number of routes that can be used in config file required edit of source code. Other required changes in different files, so we looked to simplify and unify the mode of setting most common options. A new file, Makefile.vars holds now options in format name=value where you can turn off/on compilation flags (like compile in memory debug mode), tune internal values and specify what group of modules (based on dependency) to be compile as well. So, from now on, if you want to tune compilation parameters, check first the Makefile.vars file. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

1 0

[Kamailio-Users] debian packages not found
by Amit Agarwal 15 Jan '09

15 Jan '09

Hi, I have looked into the following paths, But I could not find the required package. http://www.kamailio.org/debian/dists/stable/main/binary-i386/ http://www.kamailio.org/debian/dists/stable/non-free/binary-i386/ http://www.kamailio.org/debian/dists/etch/main/binary-i386/ http://www.kamailio.org/debian/dists/etch/non-free/binary-i386/ Also, I wish to know the difference in the packages contained in the above folders. Thanks, Regards, Amit

2 1

[Kamailio-Users] new developer: Inaki Baz Castillo
by Daniel-Constantin Mierla 14 Jan '09

14 Jan '09

Hello, here it is the proper welcome of Iñaki Baz Castillo as developer -- SourceForge id: ibc_sf. Log time community member and active contributor with troubleshooting, patches and support emails, Inaki committed his first module today (announcements sent hours ago): http://lists.kamailio.org/pipermail/devel/2009-January/017544.html He has an extensive knowledge of SIP and he is know as PITA for those writing confusing RFCs. Thanks for your work and looking forward to collaborating in the project. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

3 2

[Kamailio-Users] New module "Regex"
by Iñaki Baz Castillo 14 Jan '09

14 Jan '09

Hi all, I announce the first commit of "Regex" module to Kamailio trunk. This module offers matching operations against regular expressions using the powerful PCRE library. A text file containing regular expressions categorized in groups is compiled when the module is loaded, storing the compiled PCRE objects in an array. A function to match a string or pseudo-variable against any of these groups is provided. The text file can be modified and reloaded at any time via a MI command. The module also offers a function to perform a PCRE matching operation against a regular expression provided as function parameter. The module documentation is already online: http://kamailio.org/docs/modules/devel/regex.html The commit has been done in rev 5458: http://openser.svn.sourceforge.net/viewvc/openser?view=rev&revision=5458 Any suggestion is really welcome. -- Iñaki Baz Castillo <ibc(a)aliax.net>

3 2

[Kamailio-Users] snmpstats error
by Noel R. Morais 14 Jan '09

14 Jan '09

Hi guys, I'm trying to use the snmpstats module but on kamailio initialization it shows me the error: kamailio: ERROR:core:sr_load_module: could not open module </usr/local/lib/kamailio/modules/snmpstats.so>: /usr/lib/libnetsnmpagent.so.10: undefine d symbol: make_tempfile I've found in this lists a post asking to remove the follow line from Makefile: BUILDAGENTLIBS:=$(filter-out %netsnmpmibs, $(BUILDAGENTLIBS)) but this line doesn't exists. Does anyone know how to fix that? My system: Kamailio 1.4.2 notls CentOS 5 Kernel 2.6.18-92 Thanks in advance, Noel

3 4

[Kamailio-Users] perlvdb
by victorpy 13 Jan '09

13 Jan '09

Hello, i could be wrong but what i read from perlvdb is that using that module you abstract from the DB engine. I want to know if it's posible with this module to load a database in memory. I want to do this for performance. if is posible could you give an example, otherwise you could give a hint to solve this thanks bye -- View this message in context: http://www.nabble.com/perlvdb-tp21421051p21421051.html Sent from the OpenSER Users Mailing List mailing list archive at Nabble.com.

4 5

[Kamailio-Users] playing different announcements to user
by Luciano Afranllie 13 Jan '09

13 Jan '09

Hi, I have not experience doing this so I want to ask you what is the best approach to instruct a media server about what announcement to play to the user. For example, if I use asterisk, should I define one extension per announcement type? Is this the common approach? Thanks Luciano

4 4

Re: [Kamailio-Users] WARNING:core:send2child: no free tcp receiver
by Ali Jawad 13 Jan '09

13 Jan '09

Adding to the below I am getting these errors Jan 12 12:35:30 sero /usr/local/sbin/openser[30076]: ERROR:core:tcpconn_connect: tcp_blocking_connect failed Jan 12 12:35:30 sero /usr/local/sbin/openser[30076]: ERROR:core:tcp_send: connect failed Jan 12 12:35:30 sero /usr/local/sbin/openser[30076]: ERROR:sl:msg_send: tcp_send failed Jan 12 12:35:30 sero /usr/local/sbin/openser[30076]: ERROR:auth:challenge: failed to send the response Jan 12 12:35:31 sero /usr/local/sbin/openser[30076]: ERROR:core:tcp_blocking_connect: poll error: flags 18 Jan 12 12:35:31 sero /usr/local/sbin/openser[30076]: ERROR:core:tcp_blocking_connect: failed to retrieve SO_ERROR (111) Connection refused With Regards Ali Jawad System Administrator Splendor Telecom (www.splendor.net <outbind://210/www.splendor.net> ) Beirut, Lebanon Phone: +961 1 373725 Fax: + 961 1 375554 ________________________________ From: Ali Jawad Sent: 2009-01-12 12:33 To: Ali Jawad; users(a)lists.opensips.org Cc: users(a)lists.kamailio.org Subject: RE: [OpenSIPS-Users] WARNING:core:send2child: no free tcp receiver As an update I have retrieved this [root@sero ~]# /usr/local/sbin/openserctl ps Process:: ID=0 PID=30033 Type=attendant Process:: ID=1 PID=30036 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=2 PID=30037 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=3 PID=30038 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=4 PID=30039 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=5 PID=30041 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=6 PID=30042 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=7 PID=30043 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=8 PID=30044 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=9 PID=30045 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=10 PID=30046 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=11 PID=30047 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=12 PID=30048 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=13 PID=30049 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=14 PID=30050 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=15 PID=30051 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=16 PID=30052 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=17 PID=30053 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=18 PID=30054 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=19 PID=30055 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=20 PID=30056 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=21 PID=30057 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=22 PID=30060 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=23 PID=30062 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=24 PID=30064 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=25 PID=30065 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=26 PID=30066 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=27 PID=30067 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=28 PID=30068 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=29 PID=30069 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=30 PID=30070 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=31 PID=30071 Type=timer Process:: ID=32 PID=30072 Type=timer Process:: ID=33 PID=30073 Type=MI FIFO Process:: ID=34 PID=30074 Type=TCP receiver Process:: ID=35 PID=30075 Type=TCP receiver Process:: ID=36 PID=30076 Type=TCP receiver Process:: ID=37 PID=30077 Type=TCP receiver Process:: ID=38 PID=30079 Type=TCP receiver Process:: ID=39 PID=30080 Type=TCP receiver Process:: ID=40 PID=30081 Type=TCP receiver Process:: ID=41 PID=30082 Type=TCP receiver Process:: ID=42 PID=30084 Type=TCP receiver Process:: ID=43 PID=30085 Type=TCP receiver Process:: ID=44 PID=30086 Type=TCP receiver Process:: ID=45 PID=30087 Type=TCP receiver Process:: ID=46 PID=30090 Type=TCP receiver Process:: ID=47 PID=30091 Type=TCP receiver Process:: ID=48 PID=30092 Type=TCP receiver Process:: ID=49 PID=30094 Type=TCP receiver Process:: ID=50 PID=30095 Type=TCP receiver Process:: ID=51 PID=30096 Type=TCP receiver Process:: ID=52 PID=30097 Type=TCP receiver Process:: ID=53 PID=30098 Type=TCP receiver Process:: ID=54 PID=30099 Type=TCP receiver Process:: ID=55 PID=30100 Type=TCP receiver Process:: ID=56 PID=30101 Type=TCP receiver Process:: ID=57 PID=30102 Type=TCP receiver Process:: ID=58 PID=30103 Type=TCP receiver Process:: ID=59 PID=30104 Type=TCP receiver Process:: ID=60 PID=30105 Type=TCP receiver Process:: ID=61 PID=30107 Type=TCP receiver Process:: ID=62 PID=30109 Type=TCP receiver Process:: ID=63 PID=30110 Type=TCP receiver Process:: ID=64 PID=30111 Type=TCP main With Regards Ali Jawad System Administrator Splendor Telecom (www.splendor.net <outbind://206/www.splendor.net> ) Beirut, Lebanon Phone: +961 1 373725 Fax: + 961 1 375554 ________________________________ From: users-bounces(a)lists.opensips.org [mailto:users-bounces@lists.opensips.org] On Behalf Of Ali Jawad Sent: 2009-01-12 02:31 To: users(a)lists.opensips.org Cc: users(a)lists.kamailio.org Subject: [OpenSIPS-Users] WARNING:core:send2child: no free tcp receiver Hi All I am getting a lot of WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (7) I tried setting children to 20 that did not help, these warning start being displayed right after I start openser. Users frequently get service unavailable errors randomly when they try to connect, but I dont know if this is related to this warning message or not. As for the server there is plenty of CPU and RAM left, users range from 140 to 250 online all using tls. As for server limits I have set them to the following : You have new mail in /var/spool/mail/root [root@sero openser]# ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited pending signals (-i) 1024 max locked memory (kbytes, -l) 32 max memory size (kbytes, -m) unlimited open files (-n) 101024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 stack size (kbytes, -s) 10240 cpu time (seconds, -t) unlimited max user processes (-u) 16382 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited Is this warning message related to the serice unavailable problem, what does the warning message mean in more depth and how to get rid of it ? Thanks Getting alot of Jan 12 00:00:32 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (7) Jan 12 00:00:32 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (7) Jan 12 00:00:32 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (7) Jan 12 00:00:33 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (8) Jan 12 00:00:33 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (8) Jan 12 00:00:33 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (8) Jan 12 00:00:33 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (8) Jan 12 00:00:33 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (9) Jan 12 00:00:33 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (9) Jan 12 00:00:33 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (9) Jan 12 00:00:34 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (9) Jan 12 00:00:34 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (10) Jan 12 00:00:34 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (10) Jan 12 00:00:34 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (10) Jan 12 00:00:35 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (10) Jan 12 00:00:35 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (10) Jan 12 00:00:35 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (10)

3 4

Re: [Kamailio-Users] About Kamailio-1.4.0-notls.
by Sunil Teli 13 Jan '09

13 Jan '09

And also when I(Application A) send the Subscribe message with the Dialog event to the kamailio server, The kamailio server is not forwarding that Subscribe message to party B. Since kamailio acts as proxy it has to forward the Subscribe message to the party to whom I have Subscribed(ie Party B an x-lite phone). The call flow is as follows. REISTER A(APP) kamailio B(x-lite) C(x-lite) | | | | 200 OK | | | | | | | | REGISTER REGISTER | | | | | | | | 200 OK | | | | | | | | 200 OK | | | | | | | | SUBSCRIBE | | | | | | | | 202 OK | | | | | | | | NOTIFY | | | | Call Established between B and C | | | | 200 OK | | | | | | | | | | | | | | | | I am using kamailio-1.4.0-notls and trying to use dialog event package. The above call flow is as follows. 1) B an x-lite phone is Registered(B@kamailio) then C another x-lite phone is registered(c@kamailio) 2) Now from my application I am registering A and got registered(A@kamailio). 3) Now A is subscribing to B for the dialog event, so I am sending SUBSCRIBE message to kamailio server, that is I am sending SUBSCRIBE message from A@application to B@kamailio with the Event header. 4) Now I got 202 for the SUBSCRIBE. 5) Server Kamailio sends NOTIFY and then my application A sends 200 OK. 6) Now I will establish call between two x-lite phones B and C. Now My Question? When I establish call between B and C, I(Application A) have to get NOTIFY from kamailio server about the dialog event, I am not getting the NOTIFY for the dialog event since I have Subscribed to B for the Dialog event Package. Finally I(A application) want to know that dialog changes in the B. But Dialog module is present in the kamailio code. So for what purpose is it used? Is there any modules I have to include or provision in the config file or make file, If yes then where I have to make the changes. Thank You Regards, Sunil Teli -----Original Message----- From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] Sent: Monday, January 12, 2009 7:08 PM To: Sunil Teli Cc: users Subject: Re: [Kamailio-Users] About Kamailio-1.4.0-notls. Hi Sunil! Kamailio 1.4 does not support the "dialog" event package. You have to use Kamailio "trunk" version. Trunk includes 2 new modules: PUA_DIALOGINFO: generates PUBLISH requests to publish the dialog state PRESENCE_DIALOGINFO: processes PUBLISH requests, aggregate dialog information and send it with NOTIFY to the watcher Please see the detailed READMEs of these modules. http://www.kamailio.org/docs/modules/devel/ regards klaus ============================================================================================================================ 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 <a href="http://www.techmahindra.com/Disclaimer.html">http://www.techmahindra.com/Disclaimer.html</a> externally and <a href="http://tim.techmahindra.com/Disclaimer.html">http://tim.techmahindra.com/Disclaimer.html</a> internally within Tech Mahindra. ============================================================================================================================

3 4

[Serusers] db_query in failure_route
by John G. Rose 12 Jan '09

12 Jan '09

I noticed that a db_query in a failure route works in some situations but not in others. Is there way to make it work all the time? I know in SER <2.0 you are supposed to not do this. In 2.0 it works sometimes. Also I noticed in some db_ops documentation there is the db_proper() failure route hack fix but this is not in SER 2.0 db_ops code apparently... John

1 0

[Kamailio-Users] Segment fault with trunk version and default config file
by Iñaki Baz Castillo 12 Jan '09

12 Jan '09

Hi, I've upgraded Kamailio to the trunk version (ref 5440). i've compiled in with "make deb-etch" in my Debian Etch 64 bits as so many times. If I start Kamailio "with /etc/init.d/kamailio start" I get the following logs in which no error appear, but are obviously incomplete: ------------------------- Not starting kamailio: invalid configuration file! Jan 12 18:10:02 [8915] DBG:core:yyparse: loading module /usr/lib/kamailio/modules/sl.so Jan 12 18:10:02 [8915] DBG:core:yyparse: loading module /usr/lib/kamailio/modules/tm.so Jan 12 18:10:02 [8915] DBG:core:register_module: register_pv: tm Jan 12 18:10:02 [8915] DBG:core:pv_table_add: PV table not initialized, doing it now Jan 12 18:10:02 [8915] DBG:core:yyparse: loading module /usr/lib/kamailio/modules/rr.so Jan 12 18:10:02 [8915] DBG:core:yyparse: loading module /usr/lib/kamailio/modules/pv.so Jan 12 18:10:02 [8915] DBG:core:tr_table_add: TR table not initialized, doing it now Jan 12 18:10:02 [8915] DBG:core:register_module: register_pv: pv Jan 12 18:10:02 [8915] DBG:core:yyparse: loading module /usr/lib/kamailio/modules/maxfwd.so Jan 12 18:10:02 [8915] DBG:core:yyparse: loading module /usr/lib/kamailio/modules/usrloc.so Jan 12 18:10:02 [8915] DBG:core:yyparse: loading module /usr/lib/kamailio/modules/registrar.so Jan 12 18:10:02 [8915] DBG:core:register_module: register_pv: registrar Jan 12 18:10:02 [8915] DBG:core:yyparse: loading module /usr/lib/kamailio/modules/textops.so Jan 12 18:10:02 [8915] DBG:core:yyparse: loading module /usr/lib/kamailio/modules/mi_fifo.so Jan 12 18:10:02 [8915] DBG:core:yyparse: loading module /usr/lib/kamailio/modules/uri_db.so Jan 12 18:10:02 [8915] DBG:core:yyparse: loading module /usr/lib/kamailio/modules/siputils.so Jan 12 18:10:02 [8915] DBG:core:yyparse: loading module /usr/lib/kamailio/modules/xlog.so Jan 12 18:10:02 [8915] DBG:core:register_module: register_pv: xlog Jan 12 18:10:02 [8915] DBG:core:yyparse: loading module /usr/lib/kamailio/modules/acc.so Jan 12 18:10:02 [8915] DBG:core:set_mod_param_regex: mi_fifo matches module mi_fifo Jan 12 18:10:02 [8915] DBG:core:set_mod_param_regex: found <fifo_name> in module mi_fifo [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:set_mod_param_regex: rr matches module rr Jan 12 18:10:02 [8915] DBG:core:set_mod_param_regex: found <enable_full_lr> in module rr [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:set_mod_param_regex: rr matches module rr Jan 12 18:10:02 [8915] DBG:core:set_mod_param_regex: found <append_fromtag> in module rr [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:set_mod_param_regex: registrar matches module registrar Jan 12 18:10:02 [8915] DBG:core:set_mod_param_regex: found <method_filtering> in module registrar [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:set_mod_param_regex: uri_db matches module uri_db Jan 12 18:10:02 [8915] DBG:core:set_mod_param_regex: found <use_uri_table> in module uri_db [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:set_mod_param_regex: uri_db matches module uri_db Jan 12 18:10:02 [8915] DBG:core:set_mod_param_regex: found <db_url> in module uri_db [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:set_mod_param_regex: acc matches module acc Jan 12 18:10:02 [8915] DBG:core:set_mod_param_regex: found <early_media> in module acc [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:set_mod_param_regex: acc matches module acc Jan 12 18:10:02 [8915] DBG:core:set_mod_param_regex: found <report_ack> in module acc [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:set_mod_param_regex: acc matches module acc Jan 12 18:10:02 [8915] DBG:core:set_mod_param_regex: found <report_cancels> in module acc [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:set_mod_param_regex: acc matches module acc Jan 12 18:10:02 [8915] DBG:core:set_mod_param_regex: found <detect_direction> in module acc [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:set_mod_param_regex: acc matches module acc Jan 12 18:10:02 [8915] DBG:core:set_mod_param_regex: found <failed_transaction_flag> in module acc [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:set_mod_param_regex: acc matches module acc Jan 12 18:10:02 [8915] DBG:core:set_mod_param_regex: found <log_flag> in module acc [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:set_mod_param_regex: acc matches module acc Jan 12 18:10:02 [8915] DBG:core:set_mod_param_regex: found <log_missed_flag> in module acc [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:set_mod_param_regex: acc matches module acc Jan 12 18:10:02 [8915] DBG:core:set_mod_param_regex: found <db_flag> in module acc [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:set_mod_param_regex: acc matches module acc Jan 12 18:10:02 [8915] DBG:core:set_mod_param_regex: found <db_missed_flag> in module acc [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:set_mod_param_regex: usrloc matches module usrloc Jan 12 18:10:02 [8915] DBG:core:set_mod_param_regex: found <db_mode> in module usrloc [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:find_cmd_export_t: found <mf_process_maxfwd_header>(1) in module maxfwd [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:find_cmd_export_t: found <sl_send_reply>(2) in module sl [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:find_cmd_export_t: found <has_totag>(0) in module siputils [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:find_cmd_export_t: found <loose_route>(0) in module rr [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:find_cmd_export_t: found <is_method>(1) in module textops [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:find_cmd_export_t: found <is_method>(1) in module textops [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:find_cmd_export_t: found <t_check_trans>(0) in module tm [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:find_cmd_export_t: found <t_relay>(0) in module tm [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:find_cmd_export_t: found <sl_send_reply>(2) in module sl [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:find_cmd_export_t: found <is_method>(1) in module textops [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:find_cmd_export_t: found <t_check_trans>(0) in module tm [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:find_cmd_export_t: found <t_relay>(0) in module tm [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:find_cmd_export_t: found <t_check_trans>(0) in module tm [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:find_cmd_export_t: found <is_method>(1) in module textops [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:find_cmd_export_t: found <record_route>(0) in module rr [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:find_cmd_export_t: found <is_method>(1) in module textops [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:find_cmd_export_t: found <append_hf>(1) in module textops [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:find_cmd_export_t: found <is_method>(1) in module textops [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:find_cmd_export_t: found <sl_send_reply>(2) in module sl [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:find_cmd_export_t: found <is_method>(1) in module textops [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:find_cmd_export_t: found <save>(1) in module registrar [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:find_cmd_export_t: found <sl_reply_error>(0) in module sl [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:find_cmd_export_t: found <sl_send_reply>(2) in module sl [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:find_cmd_export_t: found <lookup>(1) in module registrar [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:find_cmd_export_t: found <t_newtran>(0) in module tm [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:find_cmd_export_t: found <t_reply>(2) in module tm [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:find_cmd_export_t: found <sl_send_reply>(2) in module sl [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:find_cmd_export_t: found <is_method>(1) in module textops [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:find_cmd_export_t: found <t_on_branch>(1) in module tm [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:find_cmd_export_t: found <t_on_reply>(1) in module tm [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:find_cmd_export_t: found <t_on_failure>(1) in module tm [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:find_cmd_export_t: found <t_relay>(0) in module tm [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:find_cmd_export_t: found <sl_reply_error>(0) in module sl [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:find_cmd_export_t: found <xlog>(1) in module xlog [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:find_cmd_export_t: found <xlog>(1) in module xlog [/usr/lib/kamailio/modules/] Jan 12 18:10:02 [8915] DBG:core:find_cmd_export_t: found <t_was_cancelled>(0) in module tm [/usr/lib/kamailio/modules/] ---------------------------------- If I run directly "kamailio" I get a segmentation fault, this explain that there is no error log above. -- Iñaki Baz Castillo <ibc(a)aliax.net>

1 0

[Kamailio-Users] About Kamailio-1.4.0-notls.
by Sunil Teli 12 Jan '09

12 Jan '09

Hi, I want to know that Kamailio-1.4.0-notls supports Dialog Event Package, If yes what configuration I have to do. If no the which version of the kamailio/OpenSER/OpenSIPS I have to use for the Dialog Event package support. Please go through the below call flow I have a problem. I am using kamailio-1.4.0-notls and trying to use dialog event package. The above call flow is as follows. 1) B an x-lite phone is Registered(B@kamailio) then C another x-lite phone is registered(c@kamailio) 2) Now from my application I am registering A and got registered(A@kamailio). 3) Now A is subscribing to B for the dialog event, so I am sending SUBSCRIBE message to kamailio server, that is I am sending SUBSCRIBE message from A@application to B@kamailio with the Event header. 4) Now I got 202 for the SUBSCRIBE. 5) Server Kamailio sends NOTIFY and then my application A sends 200 OK. 6) Now I will establish call between two x-lite phones B and C. Now My Question? When I establish call between B and C, I(Application A) have to get NOTIFY from kamailio server about the dialog event, I am not getting the NOTIFY for the dialog event since I have Subscribed to B for the Dialog event Package. Finally I(A application) want to know that dialog changes in the B Any help is appreciated to solve my problem. Advance thanks for the help. Thank You Regards, Sunil ============================================================================================================================ 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 <a href="http://www.techmahindra.com/Disclaimer.html">http://www.techmahindra.com/Disclaimer.html</a> externally and <a href="http://tim.techmahindra.com/Disclaimer.html">http://tim.techmahindra.com/Disclaimer.html</a> internally within Tech Mahindra. ============================================================================================================================

2 1

[Kamailio-Users] Kamailio (OpenSER) 1.5.0 Freezing on Jan 26, 2009
by Daniel-Constantin Mierla 12 Jan '09

12 Jan '09

Hello, we approach the time for a new stable version: http://www.kamailio.org/dokuwiki/doku.php/development:release-policy Proposed date to freeze the code is: Mon, Jan 26, 2009. It will follow about one month of testing and the the new version will be out. There is a lot of new development since last major release 1.4.0, check a summary at: http://www.kamailio.org/dokuwiki/doku.php/features:new-in-1.5.x AFAIK, before release, 2-4 new more module are going to be introduced and couple of existing modules extended. This is a notification for all users and developers (existing or upcoming) to finish the work before the freezing data if they want to get their code in Kamailio (OpenSER) 1.5.0. The 1.5.x series will be the last to use the current core. Next releases will be based on SIP Router project: http://sip-router.org/ Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

1 0

[Kamailio-Users] textops: regexp-based search/remove headers
by Daniel-Constantin Mierla 12 Jan '09

12 Jan '09

Hello, the textops module has two new functions that help to search and remove headers based on regular expressions: - is_present_hf_re(regexp) http://kamailio.org/docs/modules/devel/textops.html#id2506553 - remove_hf_re(regexp) http://kamailio.org/docs/modules/devel/textops.html#id2506863 Particularly the second is useful to remove a bunch of headers in one step. For example, if you have several proxyes in your platform and you exchange information between them via X-Something headers, then you can remove all with: remove_hf_re("^X-"); Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

1 0

Re: [Kamailio-Users] [OpenSIPS-Users] WARNING:core:send2child: no free tcp receiver
by Ali Jawad 12 Jan '09

12 Jan '09

As an update I have retrieved this [root@sero ~]# /usr/local/sbin/openserctl ps Process:: ID=0 PID=30033 Type=attendant Process:: ID=1 PID=30036 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=2 PID=30037 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=3 PID=30038 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=4 PID=30039 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=5 PID=30041 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=6 PID=30042 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=7 PID=30043 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=8 PID=30044 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=9 PID=30045 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=10 PID=30046 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=11 PID=30047 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=12 PID=30048 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=13 PID=30049 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=14 PID=30050 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=15 PID=30051 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=16 PID=30052 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=17 PID=30053 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=18 PID=30054 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=19 PID=30055 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=20 PID=30056 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=21 PID=30057 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=22 PID=30060 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=23 PID=30062 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=24 PID=30064 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=25 PID=30065 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=26 PID=30066 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=27 PID=30067 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=28 PID=30068 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=29 PID=30069 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=30 PID=30070 Type=SIP receiver udp:xx.yy.zz.aa:5060 Process:: ID=31 PID=30071 Type=timer Process:: ID=32 PID=30072 Type=timer Process:: ID=33 PID=30073 Type=MI FIFO Process:: ID=34 PID=30074 Type=TCP receiver Process:: ID=35 PID=30075 Type=TCP receiver Process:: ID=36 PID=30076 Type=TCP receiver Process:: ID=37 PID=30077 Type=TCP receiver Process:: ID=38 PID=30079 Type=TCP receiver Process:: ID=39 PID=30080 Type=TCP receiver Process:: ID=40 PID=30081 Type=TCP receiver Process:: ID=41 PID=30082 Type=TCP receiver Process:: ID=42 PID=30084 Type=TCP receiver Process:: ID=43 PID=30085 Type=TCP receiver Process:: ID=44 PID=30086 Type=TCP receiver Process:: ID=45 PID=30087 Type=TCP receiver Process:: ID=46 PID=30090 Type=TCP receiver Process:: ID=47 PID=30091 Type=TCP receiver Process:: ID=48 PID=30092 Type=TCP receiver Process:: ID=49 PID=30094 Type=TCP receiver Process:: ID=50 PID=30095 Type=TCP receiver Process:: ID=51 PID=30096 Type=TCP receiver Process:: ID=52 PID=30097 Type=TCP receiver Process:: ID=53 PID=30098 Type=TCP receiver Process:: ID=54 PID=30099 Type=TCP receiver Process:: ID=55 PID=30100 Type=TCP receiver Process:: ID=56 PID=30101 Type=TCP receiver Process:: ID=57 PID=30102 Type=TCP receiver Process:: ID=58 PID=30103 Type=TCP receiver Process:: ID=59 PID=30104 Type=TCP receiver Process:: ID=60 PID=30105 Type=TCP receiver Process:: ID=61 PID=30107 Type=TCP receiver Process:: ID=62 PID=30109 Type=TCP receiver Process:: ID=63 PID=30110 Type=TCP receiver Process:: ID=64 PID=30111 Type=TCP main With Regards Ali Jawad System Administrator Splendor Telecom (www.splendor.net <outbind://206/www.splendor.net> ) Beirut, Lebanon Phone: +961 1 373725 Fax: + 961 1 375554 ________________________________ From: users-bounces(a)lists.opensips.org [mailto:users-bounces@lists.opensips.org] On Behalf Of Ali Jawad Sent: 2009-01-12 02:31 To: users(a)lists.opensips.org Cc: users(a)lists.kamailio.org Subject: [OpenSIPS-Users] WARNING:core:send2child: no free tcp receiver Hi All I am getting a lot of WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (7) I tried setting children to 20 that did not help, these warning start being displayed right after I start openser. Users frequently get service unavailable errors randomly when they try to connect, but I dont know if this is related to this warning message or not. As for the server there is plenty of CPU and RAM left, users range from 140 to 250 online all using tls. As for server limits I have set them to the following : You have new mail in /var/spool/mail/root [root@sero openser]# ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited pending signals (-i) 1024 max locked memory (kbytes, -l) 32 max memory size (kbytes, -m) unlimited open files (-n) 101024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 stack size (kbytes, -s) 10240 cpu time (seconds, -t) unlimited max user processes (-u) 16382 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited Is this warning message related to the serice unavailable problem, what does the warning message mean in more depth and how to get rid of it ? Thanks Getting alot of Jan 12 00:00:32 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (7) Jan 12 00:00:32 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (7) Jan 12 00:00:32 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (7) Jan 12 00:00:33 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (8) Jan 12 00:00:33 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (8) Jan 12 00:00:33 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (8) Jan 12 00:00:33 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (8) Jan 12 00:00:33 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (9) Jan 12 00:00:33 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (9) Jan 12 00:00:33 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (9) Jan 12 00:00:34 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (9) Jan 12 00:00:34 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (10) Jan 12 00:00:34 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (10) Jan 12 00:00:34 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (10) Jan 12 00:00:35 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (10) Jan 12 00:00:35 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (10) Jan 12 00:00:35 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (10)

1 0

[Kamailio-Users] WARNING:core:send2child: no free tcp receiver
by Ali Jawad 12 Jan '09

12 Jan '09

Hi All I am getting a lot of WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (7) I tried setting children to 20 that did not help, these warning start being displayed right after I start openser. Users frequently get service unavailable errors randomly when they try to connect, but I dont know if this is related to this warning message or not. As for the server there is plenty of CPU and RAM left, users range from 140 to 250 online all using tls. As for server limits I have set them to the following : You have new mail in /var/spool/mail/root [root@sero openser]# ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited pending signals (-i) 1024 max locked memory (kbytes, -l) 32 max memory size (kbytes, -m) unlimited open files (-n) 101024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 stack size (kbytes, -s) 10240 cpu time (seconds, -t) unlimited max user processes (-u) 16382 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited Is this warning message related to the serice unavailable problem, what does the warning message mean in more depth and how to get rid of it ? Thanks Getting alot of Jan 12 00:00:32 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (7) Jan 12 00:00:32 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (7) Jan 12 00:00:32 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (7) Jan 12 00:00:33 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (8) Jan 12 00:00:33 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (8) Jan 12 00:00:33 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (8) Jan 12 00:00:33 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (8) Jan 12 00:00:33 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (9) Jan 12 00:00:33 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (9) Jan 12 00:00:33 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (9) Jan 12 00:00:34 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (9) Jan 12 00:00:34 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (10) Jan 12 00:00:34 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (10) Jan 12 00:00:34 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (10) Jan 12 00:00:35 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (10) Jan 12 00:00:35 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (10) Jan 12 00:00:35 sero /usr/local/sbin/openser[28281]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (10)

1 0

[Serusers] ser behind NAT
by WANG Zhenzhong 11 Jan '09

11 Jan '09

Hi every body My SER is behind NAT, so when SER forward INVITE message, the VIA must be set to the public IP How? Thank you very much. 王振中 wangzz 艾诺通信系统（苏州）有限责任公司苏州工业园区国际科技园一期203A wangzz(a)avonaco.com ============================================

4 4

[Kamailio-Users] compare uri and aor
by Daniel-Constantin Mierla 11 Jan '09

11 Jan '09

Hello, I have introduced in siputils module functions to compare SIP URI and AoR in a more RFC manner, related to: https://sourceforge.net/tracker/index.php?func=detail&aid=2047019&group_id=… Now, for URI it does comparison of: - username - password - hostname - port For AoR, it does: - username - hostname - port (if port is missing, it assumes 5060 -- for URI comparison this is not used, conform to RFC3261) The questions are: - shall the comparison for URI be extended to follow full RFC? could get complex when taking URI headers in account -- haven't seen many, but the RFC allow them. Where to stop then the rules for comparing the URI? - for AoR, I am not sure if port should be considered, but when running multiple instances on different ports, it may make the difference? What do you think? Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

3 5

[Serusers] SER monitoring capabilities
by Martin Lane 09 Jan '09

09 Jan '09

I'm looking for some information on the ability to monitor (have an indication of activity of, not listen too) the active calls real-time with the SER/SEMS suite. Can this be done and is anyone doing that? mll

3 2

[Serusers] SER monitoring capabilities
by Martin Lane 09 Jan '09

09 Jan '09

I'm looking for some information on the ability to monitor (have an indication of activity of not listen too) the active calls real-time with the SER/SEMS suite. Can this be done and is anyone doing that? mll

1 0

[Kamailio-Users] Help!! Getting get_hdr_field: out of memory
by Krunal Patel 09 Jan '09

09 Jan '09

Hi, I am using openser 1.2.3. I have increased PKG_MEM_POOL_SIZE to 4MB. Openser worked properly for 4 days since last restart. I found get_hdr_field: out of memory for all messages. I did openser restart & the issue is fixed now. Is anybody there who have faced the same issue? Thanks in advance!! -- Krunal patel

2 15

[Kamailio-Users] Internet drops and ATA don´t register
by MagoDaViola 09 Jan '09

09 Jan '09

Untitled Document Hello all .... I'm having a problem with our server or customers. Most of our clients access the server using the combination ATA and ADSL Modem, but when the ADSL drops and returns in a few minutes, the ATA can no longer make the register on SIP server. Sometimes passing through the modem or the requests of the ATA. I identified that this happens a lot with the D-Link modems DSL-500B and siemens SpeedStream 4200. If someone went through this I would your help ... thanks -------------------------------------------------------------------------- Alcindo Schleder Sistema Processa Acessoria e Comunicações Ltda. a.. MSN: a_schleder(a)hotmail.com b.. Skipe: alcindo_schleder Demétrio P. dos Santos, 705 - 95670-000 - Gramado-RS-Brasil Celular + 55 54 9966 7591 alcindo(a)processa.org Fone +55 54 3286-1738 comercial(a)processa.org

9 34

[Kamailio-Users] Perl var main script access
by Luis Guaman 08 Jan '09

08 Jan '09

Hi , How can I get access in the onreply_route main script section for a variable set in a perl which is called from a previous route[] section?? Thanks in advance Luis Guaman Interlancompu

3 3

[Kamailio-Users] I need termine a call then timeout.
by igor 08 Jan '09

08 Jan '09

I need termine a call then timeout. but, return a message WARNING and do not Hangup! help me! WARNING:dialog:get_expired_dlgs: start with tl=0xb5a11a20 tl->prev=0xb59cf550 tl->next=0xb59cf550 (101) at 101 and end with end=0xb59cf550 end->prev=0xb5a11a20 end->next=0xb5a11a20 WARNING:dialog:get_expired_dlgs: getting tl=0xb5a11a20 tl->prev=0xb59cf550 tl->next=0xb59cf550 with 101 WARNING:dialog:get_expired_dlgs: end with tl=0xb59cf550 tl->prev=0xb5a11a20 tl->next=0xb5a11a20 and d_timer->first.next->prev=(nil) WARNING:dialog:dlg_ontimeout: timeout for dlg with CallID 'T8x-xgYUoIe3707wDPg1qwq-AX4o3m' and tags '9697t1cm3thc6l2207g9' '7jju88u987' loadmodule "dialog.so" modparam("dialog", "enable_stats", 1) modparam("dialog", "db_url", "mysql://user:pass@localhost/openser") modparam("dialog", "db_mode", 1) modparam("dialog", "dlg_flag", 4) modparam("dialog", "timeout_avp", "$avp(s:dlgtimeout)") modparam("dialog", "dlg_extra_hdrs", "Hint: credit expired\r\n") modparam("dialog", "dlg_match_mode", 1) modparam("dialog", "default_timeout", 10) if(is_method("INVITE")) { $avp(s:dlgtimeout)=5; $avp(s:ringtimeout)=10; setflag(4); route(4); } Atenciosamente, Igor Marques celular: 55 21 7858 7499 nextel: 87*24074 e-mail: igor(a)carneiro.cc web: www.carneiro.cc -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

3 7

[Kamailio-Users] Accounting: How to avoid a fraudulent BYE with lower CSeq?
by Iñaki Baz Castillo 08 Jan '09

08 Jan '09

Hi, first of all I'm sorry for this cross-posting, but I think it could be interesting for any SIP proxy with accounting capabilities. I'm thinking in the following flow in which the caller/attacker would get an unlimited call (but a limited CDR duration): -------------------------------------------------------------------------- attacker Kamailio (Acc) gateway INVITE (CSeq 12) ------> <-------- 407 Proxy Auth INVITE (CSeq 13) ------> INVITE (CSeq 13) ------> <------------------- 200 Ok <------------------- 200 Ok << Acc START >> ACK (CSeq 13) -----------> ACK (CSeq 13) -----------> <******************* RTP ************************> # Fraudulent BYE !!! BYE (CSeq 10) -----------> << Acc STOP >> BYE (CSeq 10) -----------> <-- 500 Req Out of Order <-- 500 Req Out of Order -------------------------------------------------------------------------- The call hasn't finished, but Kamailio has ended the accounting for this call since it received a BYE. And this BYE will generate a correct ACC Stop action (since it matches From_tag, To_tag and Call-ID). I think this is *VERY* dangerous and I hope I'm wrong. Would help the dialog module here? does the dialog module check the CSeq of the BYE in some way and could it prevent Kamailio from generating the ACC STOP action? (I don't think so). I've also asked in SIP-implementors and an idea could be generating the ACC STOP action when receiving the 200 OK for the BYE (and not when receiving the BYE itself). Of course this will be valid when the gateway is the recipient of the BYE (and we know the gateway is not an "attacker"), but this is not valid when the recipient of the BYE is an user since it could send no reply for the BYE. The only solution I see is: - Using the dialog module, Kamailio should check the CSeq value in the BYE. 1) Kamailio should forward the BYE just in case the CSeq is higher than the actual CSeq for this dialog direction. 2) Kamailio should generate the ACC STOP action just in case the CSeq is higher than the actual CSeq for this dialog direction. Both 1) and 2) are needed since a gateway could accept a BYE with wrong CSeq. In this case the call is ended but the accounting STOP action doesn't exist (infinite call). But I think this is too complex, isn't it? -- Iñaki Baz Castillo <ibc(a)aliax.net>

8 47

[Kamailio-Users] (no subject)
by igor 08 Jan '09

08 Jan '09

WARNING:dialog:get_expired_dlgs: start with tl=0xb5a11a20 tl->prev=0xb59cf550 tl->next=0xb59cf550 (101) at 101 and end with end=0xb59cf550 end->prev=0xb5a11a20 end->next=0xb5a11a20 Jan 8 11:52:22 voip01 /usr/sbin/kamailio[12596]: WARNING:dialog:get_expired_dlgs: getting tl=0xb5a11a20 tl->prev=0xb59cf550 tl->next=0xb59cf550 with 101 Jan 8 11:52:22 voip01 /usr/sbin/kamailio[12596]: WARNING:dialog:get_expired_dlgs: end with tl=0xb59cf550 tl->prev=0xb5a11a20 tl->next=0xb5a11a20 and d_timer->first.next->prev=(nil) Jan 8 11:52:22 voip01 /usr/sbin/kamailio[12596]: WARNING:dialog:dlg_ontimeout: timeout for dlg with CallID 'T8x-xgYUoIe3707wDPg1qwq-AX4o3m' and tags '9697t1cm3thc6l2207g9' '7jju88u987' Atenciosamente, Igor Marques celular: 55 21 7858 7499 nextel: 87*24074 e-mail: igor(a)carneiro.cc web: www.carneiro.cc -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

1 0

[Serusers] SER server reload
by Leon Li 08 Jan '09

08 Jan '09

Dear all, I am new to SER and on a project to reload company's SER server for some SIP testing. However, I couldn't start SER after compiling. Every time I run "/usr/local/sbin/ser -f /PATH/ser.cfg", I got "ERROR: bad config file (1 errors)". Does this mean my ser.cfg has something wrong or where can I trace the logs for errors? Also, how do I uninstall the old SER and run a clean installation? Any suggestion would be appreciated. Best regards, Leon Leon Li | IT Engineer | Application & Services | AARNet Pty Ltd ________________________________ street address: Level 2, Binary Centre, Bldg1, 3 Richardson Place, North Ryde, NSW 2113 t. +61 2 9779 6937 m. 0403 603 473 e. leon.li(a)aarnet.edu.au w. www.aarnet.edu.au <http://www.aarnet.edu.au/> ________________________________ important This email and any files transmitted with it are confidential, and the rights of confidentiality in such information are not waived or lost by its mistaken delivery to you. Any dissemination, copying, use or disclosure of the email and/or such files without the permission of AARNet, or the sender, is strictly prohibited. If you have received this email in error, please contact the sender immediately and delete all copies of this transmission.

2 1

[Kamailio-Users] prepaid system
by igor 08 Jan '09

08 Jan '09

I need implement a prepaid system in my kamilio ! anybody help me !? any information ! Atenciosamente, Igor Marques celular: 55 21 7858 7499 nextel: 87*24074 e-mail: igor(a)carneiro.cc web: www.carneiro.cc -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

10 28

Re: [Kamailio-Users] how can I add .sar file as application to Wesip application server
by skumar453＠gmail.com 08 Jan '09

08 Jan '09

Hi thanku for reply while i am running the click2dial application i am getting the message like bellow ConvergedHostDeployer [main] - Installing web application at context path /click2call-08_11_06 from URL file:/usr/wesip/wesipapps/click2call-08_11_06 the log file geting while running the application is StandardAppSessionManager [main] - Force random number initialization completed processJars: cannot find /WEB-INF/lib ConvergedContext [main] - ConvergedContext [Welcome] has been started StandardService [main] - > Default Wesip Application ==> http://localhost:5075/ > Manager Wesip Application ==> http://localhost:5075/manager/html? StandardService [main] - > In order to access the manager application use default credentials: - username: wesip - password: wesip > This configuration is defined in wesip-users.xml inside conf folder: - file: ./conf/wesip-users.xml here i am not clear how to test this application ..can u please suggest me about this On Jan 7, 2009 8:27pm, Ginés Gómez <gines(a)voztele.com> wrote: > Hi, > > > > > > you can simply copy the .sar file at the wesipapps directory > > > > > > Regards > > > > > > Gines > > > > > > > > hi all > > > > > > I am workin on the "WeSIP" application server. I installed opensips as proxy with SEAS module and wesip as Application server. > > > these two are successfully connected ...but here i have no clue on how to add application "click2dial" to WeSIP. > > > > > > 1. please let me know how can I add .sar file as application. > > > 2. http://localhost:5075/manager/html? is showig a blank page. how can I get this page displayed? > > > > > > regards > > > suresh_______________________________________________ > > > Users mailing list > > > Users(a)lists.kamailio.org > > > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users > > > > > > > >

1 0

[Kamailio-Users] carrierroute prioritize gateways
by Juan Asencio 07 Jan '09

07 Jan '09

Hi list, I'm reading some old post in order to implement carrierroute. I found this in a post that I include at the end of this message, but the part that I want to ask about is this one: "You can put all the carriers under the same table and prioritize the gateway based on domains. Like tis you don't need to hardcode anything in the config file" If I do this, do I need to prioritize the gateways on the subscriber table and if is there, how do I do it for the domain, when it is only a cr_preferred_carrier field? Cheers, Juan.- [OpenSER-Users] Carrierroute *Ovidiu Sas* osas at voipembedded.com <mailto:users%40lists.kamailio.org?Subject=%5BOpenSER-Users%5D%20Carrierrout…> /Wed Mar 26 04:57:54 CET 2008/ * Previous message: [OpenSER-Users] Carrierroute <http://lists.opensips.org/pipermail/users/2008-March/016657.html> * Next message: [OpenSER-Users] [FEATURE REQ] allow does_uri_exist() to test against other variables besides $ru <http://lists.opensips.org/pipermail/users/2008-March/016658.html> * *Messages sorted by:* [ date ] <http://lists.opensips.org/pipermail/users/2008-March/date.html#16659> [ thread ] <http://lists.opensips.org/pipermail/users/2008-March/thread.html#16659> [ subject ] <http://lists.opensips.org/pipermail/users/2008-March/subject.html#16659> [ author ] <http://lists.opensips.org/pipermail/users/2008-March/author.html#16659> ------------------------------------------------------------------------ Hello Douglas, I am using this module in production with more then 400k routes loaded for 8 different providers and it is working like a charm. As Henning mentioned, the interface is a little bit cumbersome but usable. You can put all the carriers under the same table and prioritize the gateway based on domains. Like tis you don't need to hardcode anything in the config file. Carrierroute was designed to deal with a big amount of routing rules and it is doing an amazing job. LCR was designed to deal with a limited number of routes/gateways but it has a different level of flexibility and a more mature interface. Carrierroute is a brand new module and for sure it will improve in flexibility as times go by (just like the lcr did along releases). Hope this helps, Ovidiu Sas

2 3

[Kamailio-Users] dialplan and carrierroute
by victorpy 07 Jan '09

07 Jan '09

hello, sorry for the other message. i want to know if there is a way of routing based on patern matching using caller-id. Basically, i want to route through a carrier if the call-id have some pattern Eg.: international is 002-(country code)-(area code)-697699. Long distance is (country code) -(area code) -123456 Local is 123456 The international and long distance change If international then route through carrier1 else if long distance the route through carrier 2 else if local then route through carrier 3 -- View this message in context: http://www.nabble.com/dialplan-and-carrierroute-tp21331266p21331266.html Sent from the OpenSER Users Mailing List mailing list archive at Nabble.com.

2 2

[Kamailio-Users] how can I add .sar file as application to Wesip application server
by skumar453＠gmail.com 07 Jan '09

07 Jan '09

hi all I am workin on the "WeSIP" application server. I installed opensips as proxy with SEAS module and wesip as Application server. these two are successfully connected ...but here i have no clue on how to add application "click2dial" to WeSIP. 1. please let me know how can I add .sar file as application. 2. http://localhost:5075/manager/html? is showig a blank page. how can I get this page displayed? regards suresh

2 1

[Kamailio-Users] moving my kamilio1.2 server to opensips
by Asim Riaz 07 Jan '09

07 Jan '09

Hi, could anyone advice me, I like to move my Kamalio 1.2 server to Opensips ? is it possible to move all the exisitng configuration transparently? Thanks in Advance. -Asim

3 3

[Kamailio-Users] Regarding 600 bussy every where when i Forward INVITe message from b2bua to scscf
by sureshkumar.jaiswal 07 Jan '09

07 Jan '09

Hi when i ran b2bua_simple.py like this python b2bua_simple.py -f -l 172.18.2.187 -p 99999 -n 172.18.2.187 b2bua_simple.py is running 172.18.2.187 and port for this is 99999 and scscf is also running 172.18.2.187:6060 and forward my INVITE message from scscf to b2bua_simple then b2bua got this INVITE message but when b2bua again forward to scscf then we getting 600 bussy every where and call has been terminated. folllowing message i have attache along this mail. can any one let me know what i have to do for successfull call using b2bua_simple.py. python b2bua_simple.py -f -l 172.18.2.187 -p 99999 -n 172.18.2.187 08 Jan 15:26:22/GLOBAL/b2bua: RECEIVED message from 172.18.2.187:6060: INVITE sip:alice@info-spectrum.com SIP/2.0 Record-Route: <sip:mo@scscf.info-spectrum.com:6060;lr> Route: <sip:172.18.2.187:99999;lr>, <sip:iscmark@scscf.info-spectrum.com:6060;lr;s=1;h=0;d=0;a=7369703a626f6240696e666f2d737065637472756d2e636f6d> Record-Route: <sip:mo@pcscf.info-spectrum.com:4060;lr> Via: SIP/2.0/UDP 172.18.2.187:6060;branch=z9hG4bK2ede.b679b107.0 Via: SIP/2.0/UDP 172.18.2.187:4060;branch=z9hG4bK2ede.baaf9433.0 Via: SIP/2.0/UDP 172.18.2.74:2423;rport=2423;branch=z9hG4bK32209 From: <sip:bob@info-spectrum.com>;tag=9791 To: <sip:alice@info-spectrum.com> Call-ID: 1231260517025(a)172.18.2.74 CSeq: 201 INVITE Max-Forwards: 15 Allow: INVITE,ACK,CANCEL,BYE,MESSAGE,OPTIONS,UPDATE,NOTIFY,PRACK Contact: <sip:bob@172.18.2.74:2423;transport=udp>;expires=1000 User-Agent: Mercuro IMS Client Beta (4.0.1011.0) Supported: sdp-anat Content-Type: application/sdp P-Access-Network-Info: 3GPP-UTRAN-TDD;utran-cell-id-3gpp=00000000 Privacy: none Content-Length: 468 P-Asserted-Identity: <sip:bob@info-spectrum.com> P-Charging-Vector: icid-value="P-CSCFabcd4965cdc6000000ea";icid-generated-at=172.18.2.187;orig-ioi="info-spectrum.com" Timestamp: 1231408582 v=0 o=- 3344 3344 IN IP4 172.18.2.74 s=Mercuro IMS Client Session t=0 0 m=audio 30904 RTP/AVP 0 8 101 c=IN IP4 172.18.2.74 a=rtpmap:0 PCMU/8000/1 a=rtpmap:8 PCMA/8000/1 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 m=video 30080 RTP/AVP 111 34 31 c=IN IP4 172.18.2.74 a=rtpmap:111 H263-1998/90000 a=fmtp:111 CIF=2;QCIF=2/MaxBR=2400 a=rtpmap:34 H263/90000 a=fmtp:34 CIF=2;QCIF=2/MaxBR=2400 a=rtpmap:31 H261/90000 a=fmtp:31 CIF=2;QCIF=2/MaxBR=2400 08 Jan 15:26:22/GLOBAL/b2bua: SENDING message to 172.18.2.187:6060: SIP/2.0 100 Trying Via: SIP/2.0/UDP 172.18.2.187:6060;branch=z9hG4bK2ede.b679b107.0 Via: SIP/2.0/UDP 172.18.2.187:4060;branch=z9hG4bK2ede.baaf9433.0 Via: SIP/2.0/UDP 172.18.2.74:2423;rport=2423;branch=z9hG4bK32209 Record-Route: <sip:mo@scscf.info-spectrum.com:6060;lr> Record-Route: <sip:mo@pcscf.info-spectrum.com:4060;lr> From: <sip:bob@info-spectrum.com>;tag=9791 To: <sip:alice@info-spectrum.com> Call-ID: 1231260517025(a)172.18.2.74 CSeq: 201 INVITE Server: Sippy B2BUA (Simple) 08 Jan 15:26:22/GLOBAL/b2bua: SENDING message to 172.18.2.187:5060: INVITE sip:alice@172.18.2.187:5060 SIP/2.0 Via: SIP/2.0/UDP 172.18.2.187:99999;branch=z9hG4bK8801d0c21346d39cb48f86a2abbedc18;rport Max-Forwards: 70 From: <sip:bob@172.18.2.187>;tag=7cb0f980e37d8198e1c1dfeb4af2e531 To: <sip:alice@172.18.2.187> Call-ID: 1231260517025(a)172.18.2.74 CSeq: 200 INVITE Contact: Anonymous <sip:bob@172.18.2.187:99999> Expires: 300 User-Agent: Sippy B2BUA (Simple) cisco-GUID: 288073477-2250398923-1693218158-3417804826 h323-conf-id: 288073477-2250398923-1693218158-3417804826 Content-Length: 468 Content-Type: application/sdp v=0 o=- 3344 3344 IN IP4 172.18.2.74 s=Mercuro IMS Client Session t=0 0 m=audio 30904 RTP/AVP 0 8 101 c=IN IP4 172.18.2.74 a=rtpmap:0 PCMU/8000/1 a=rtpmap:8 PCMA/8000/1 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 m=video 30080 RTP/AVP 111 34 31 c=IN IP4 172.18.2.74 a=rtpmap:111 H263-1998/90000 a=fmtp:111 CIF=2;QCIF=2/MaxBR=2400 a=rtpmap:34 H263/90000 a=fmtp:34 CIF=2;QCIF=2/MaxBR=2400 a=rtpmap:31 H261/90000 a=fmtp:31 CIF=2;QCIF=2/MaxBR=2400 08 Jan 15:26:23/GLOBAL/b2bua: RECEIVED message from 172.18.2.187:5060: SIP/2.0 100 trying -- your call is important to us Via: SIP/2.0/UDP 172.18.2.187:99999;branch=z9hG4bK8801d0c21346d39cb48f86a2abbedc18;rport=34463 From: <sip:bob@172.18.2.187>;tag=7cb0f980e37d8198e1c1dfeb4af2e531 To: <sip:alice@172.18.2.187> Call-ID: 1231260517025(a)172.18.2.74 CSeq: 200 INVITE Server: Sip EXpress router (2.1.0-dev1 OpenIMSCore (i386/linux)) Content-Length: 0 Timestamp: 1231408582 Warning: 392 172.18.2.187:5060 "Noisy feedback tells: pid=3661 req_src_ip=172.18.2.187 req_src_port=34463 in_uri=sip:alice@172.18.2.187:5060 out_uri=sip:alice@172.18.2.187:5060 via_cnt==1" 08 Jan 15:26:33/GLOBAL/b2bua: RECEIVED message from 172.18.2.187:5060: SIP/2.0 600 Busy everywhere - Forwarding to S-CSCF failed Via: SIP/2.0/UDP 172.18.2.187:99999;branch=z9hG4bK8801d0c21346d39cb48f86a2abbedc18;rport=34463 From: <sip:bob@172.18.2.187>;tag=7cb0f980e37d8198e1c1dfeb4af2e531 To: <sip:alice@172.18.2.187>;tag=0fb5d9176cb7d6a1cb577893687b8ec9-47d1 Call-ID: 1231260517025(a)172.18.2.74 CSeq: 200 INVITE Server: Sip EXpress router (2.1.0-dev1 OpenIMSCore (i386/linux)) Content-Length: 0 Timestamp: 1231408593 Warning: 392 172.18.2.187:5060 "Noisy feedback tells: pid=3664 req_src_ip=172.18.2.187 req_src_port=5060 in_uri=sip:alice@172.18.2.187:5060 out_uri=sip:alice@172.18.2.187:5060 via_cnt==0" 08 Jan 15:26:33/GLOBAL/b2bua: SENDING message to 172.18.2.187:5060: ACK sip:alice@172.18.2.187:5060 SIP/2.0 Via: SIP/2.0/UDP 172.18.2.187:99999;rport;branch=z9hG4bK8801d0c21346d39cb48f86a2abbedc18 Max-Forwards: 70 From: <sip:bob@172.18.2.187>;tag=7cb0f980e37d8198e1c1dfeb4af2e531 To: <sip:alice@172.18.2.187>;tag=0fb5d9176cb7d6a1cb577893687b8ec9-47d1 Call-ID: 1231260517025(a)172.18.2.74 CSeq: 200 ACK Expires: 300 User-Agent: Sippy B2BUA (Simple) 08 Jan 15:26:33/GLOBAL/b2bua: SENDING message to 172.18.2.187:6060: SIP/2.0 600 Busy everywhere - Forwarding to S-CSCF failed Via: SIP/2.0/UDP 172.18.2.187:6060;branch=z9hG4bK2ede.b679b107.0 Via: SIP/2.0/UDP 172.18.2.187:4060;branch=z9hG4bK2ede.baaf9433.0 Via: SIP/2.0/UDP 172.18.2.74:2423;rport=2423;branch=z9hG4bK32209 Record-Route: <sip:mo@scscf.info-spectrum.com:6060;lr> Record-Route: <sip:mo@pcscf.info-spectrum.com:4060;lr> From: <sip:bob@info-spectrum.com>;tag=9791 To: <sip:alice@info-spectrum.com>;tag=2ac46b4f62d11be3189628535aa7b381 Call-ID: 1231260517025(a)172.18.2.74 CSeq: 201 INVITE Server: Sippy B2BUA (Simple) 08 Jan 15:26:33/GLOBAL/b2bua: RECEIVED message from 172.18.2.187:6060: ACK sip:alice@info-spectrum.com SIP/2.0 Via: SIP/2.0/UDP 172.18.2.187:6060;branch=z9hG4bK2ede.b679b107.0 From: <sip:bob@info-spectrum.com>;tag=9791 Call-ID: 1231260517025(a)172.18.2.74 To: <sip:alice@info-spectrum.com>;tag=2ac46b4f62d11be3189628535aa7b381 CSeq: 201 ACK Route: <sip:orig@scscf.info-spectrum.com:6060;lr> User-Agent: Sip EXpress router(2.1.0-dev1 OpenIMSCore (i386/linux)) Content-Length: 0

2 1

[Serusers] Large MTU Size of SIP Invites
by Jai Rangi 06 Jan '09

06 Jan '09

All, Greeting, I am using ser as a proxy to forward calls to Asterisk servers. When I forward the calls the total packet size is anywhere between 1505 to 1520. So the packets are frangmented. Some asterisks behind the firewall are not able to handle the franented sip packets of size 1500+. Is there a way to reduce the packets size to less than 1500. Any hint will be be appreciated. Thank you, Regards, -jai

2 1

[Kamailio-Users] dialplan and carrierroute
by victorpy 05 Jan '09

05 Jan '09

-- View this message in context: http://www.nabble.com/dialplan-and-carrierroute-tp21299057p21299057.html Sent from the OpenSER Users Mailing List mailing list archive at Nabble.com.

1 0

[Kamailio-Users] extending carrierroute to load dynamic carriers
by victorpy 05 Jan '09

05 Jan '09

Hello, I want to extend the module to load a carrier tree based on $si(source ip) of a request. I want know if im going the right way doing this. The reason why im doing this is to avoid a hardcoded script. I have read other post that talk about this subject and the solution with domains and host doesn't meet my needs. Hope someone could help me. thanks for the answers greetings -- View this message in context: http://www.nabble.com/extending-carrierroute-to-load-dynamic-carriers-tp212… Sent from the OpenSER Users Mailing List mailing list archive at Nabble.com.

3 5

[Kamailio-Users] Setting answer timeout
by mayamatakeshi 05 Jan '09

05 Jan '09

Hello, I know I can customize the timeout for answer using fr_inv_timer: modparam("tm", "fr_inv_timer", 20) But is it possible to set the answer timeout on a transaction basis? (so that it can be customized by subscriber for example). regards, mayama

2 2

[Kamailio-Users] Owner of rtpproxy.sock
by Franz Edler 05 Jan '09

05 Jan '09

Hello experts! I have a problem with the owner of rtpproxy.sock. When I use the -u parameter at start of rtpproxy like "rtpproxy -s unix:/var/run/rtpproxy.sock -u sip:sip" the owner and group of the socket is still "root root". Is this correct? Should not it be sip sip? I want to avoid kamailio running as root and therefore I have to modify the permissions of rtpproxy.sock after start of rtpproxy accordingly. My question now is: Maybe I have a misunderstanding in the purpose of the -u parameter. What is the behaviour of the -u parameter? Can anyone shed some light on this? Regards Franz

2 4

[Kamailio-Users] Bring India together
by Sunkara RaviPrakash 04 Jan '09

04 Jan '09

1 0

[Kamailio-Users] Bring India together
by Sunkara RaviPrakash 04 Jan '09

04 Jan '09

1 0

[Kamailio-Users] trying to use call park for similar a music on hold
by Ricky Gutierrez 31 Dec '08

31 Dec '08

Hi list, I am trying to make work to the parking of calls with openser and asterisk, which I want to do is when two UAC are in the middle of a call one of them can transfer a call with *700 and this is sent to asterisk to the extension by default... the problem here is that when I make the transfer to the extension 700 the asterisk it doesn't return it to the extension that I originate the transfer, the call it returns to the extension in delay .. I can see when I make the transfer in the SDP that the openser puts me c=IN IP4 0.0.0.0 , but asterisk doesn't return the call to the extension that I originate the transfer U +2.857758 192.168.10.40:5060 -> 192.168.10.1:5060 INVITE sip:*700@192.168.10.1:5070 SIP/2.0 Via: SIP/2.0/UDP 192.168.10.40:5060;branch=z9hG4bK1a7bc3cdf6e22598 Route: <sip:192.168.10.1;lr=on;ftag=0d380f28344df9f2> From: "Ventas" <sip:112@192.168.10.1>;tag=0d380f28344df9f2 To: <sip:*700@192.168.10.1>;tag=as5aea7a9e Contact: <sip:112@192.168.10.40:5060;transport=udp> Supported: replaces, timer, path Referred-By: <sip:120@192.168.10.38:5060> Proxy-Authorization: Digest username="112", realm="192.168.10.1", algorithm=MD5, uri="sip:*700@192.168.10.1:5070", nonce="495ac4ad695509e755aba895780497e8116e6353", response="40021b3138cbfefcd079505a55c6043f" Call-ID: f69f46f8461d45e0(a)192.168.10.40 CSeq: 55344 INVITE User-Agent: Grandstream GXP2020 1.1.6.16 Max-Forwards: 70 Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE Content-Type: application/sdp Content-Length: 352 v=0 o=112 8001 8002 IN IP4 192.168.10.40 s=SIP Call c=IN IP4 0.0.0.0 t=0 0 m=audio 5006 RTP/AVP 0 18 3 97 2 9 101 a=sendonly a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=rtpmap:3 GSM/8000 a=rtpmap:97 iLBC/8000 a=fmtp:97 mode=20 a=rtpmap:2 G726-32/8000 a=rtpmap:9 G722/16000 a=ptime:20 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-11 # U +0.000646 192.168.10.1:5060 -> 192.168.10.40:5060 SIP/2.0 100 Giving a try Via: SIP/2.0/UDP 192.168.10.40:5060;branch=z9hG4bK1a7bc3cdf6e22598 From: "Ventas" <sip:112@192.168.10.1>;tag=0d380f28344df9f2 To: <sip:*700@192.168.10.1>;tag=as5aea7a9e Call-ID: f69f46f8461d45e0(a)192.168.10.40 CSeq: 55344 INVITE Server: OpenSER (1.3.4-notls (i386/linux)) Content-Length: 0 # U +0.000078 192.168.10.1:5060 -> 192.168.10.1:5070 INVITE sip:*700@192.168.10.1:5070 SIP/2.0 Record-Route: <sip:192.168.10.1;lr=on;ftag=0d380f28344df9f2> Via: SIP/2.0/UDP 192.168.10.1;branch=z9hG4bK537.cbf8a716.0 Via: SIP/2.0/UDP 192.168.10.40:5060;branch=z9hG4bK1a7bc3cdf6e22598 From: "Ventas" <sip:112@192.168.10.1>;tag=0d380f28344df9f2 To: <sip:*700@192.168.10.1>;tag=as5aea7a9e Contact: <sip:112@192.168.10.40:5060;transport=udp> Supported: replaces, timer, path Referred-By: <sip:120@192.168.10.38:5060> Proxy-Authorization: Digest username="112", realm="192.168.10.1", algorithm=MD5, uri="sip:*700@192.168.10.1:5070", nonce="495ac4ad695509e755aba895780497e8116e6353", response="40021b3138cbfefcd079505a55c6043f" Call-ID: f69f46f8461d45e0(a)192.168.10.40 CSeq: 55344 INVITE User-Agent: Grandstream GXP2020 1.1.6.16 Max-Forwards: 69 Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE Content-Type: application/sdp Content-Length: 352 v=0 o=112 8001 8002 IN IP4 192.168.10.40 s=SIP Call c=IN IP4 0.0.0.0 t=0 0 m=audio 5006 RTP/AVP 0 18 3 97 2 9 101 a=sendonly a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=rtpmap:3 GSM/8000 a=rtpmap:97 iLBC/8000 a=fmtp:97 mode=20 a=rtpmap:2 G726-32/8000 a=rtpmap:9 G722/16000 a=ptime:20 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-11 # U +0.000263 192.168.10.1:5070 -> 192.168.10.1:5060 SIP/2.0 100 Trying Via: SIP/2.0/UDP 192.168.10.1;branch=z9hG4bK537.cbf8a716.0;received=192.168.10.1 Via: SIP/2.0/UDP 192.168.10.40:5060;branch=z9hG4bK1a7bc3cdf6e22598 Record-Route: <sip:192.168.10.1;lr=on;ftag=0d380f28344df9f2> From: "Ventas" <sip:112@192.168.10.1>;tag=0d380f28344df9f2 To: <sip:*700@192.168.10.1>;tag=as5aea7a9e Call-ID: f69f46f8461d45e0(a)192.168.10.40 CSeq: 55344 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Contact: <sip:*700@192.168.10.1:5070> Content-Length: 0 # U +0.000104 192.168.10.1:5070 -> 192.168.10.1:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.10.1;branch=z9hG4bK537.cbf8a716.0;received=192.168.10.1 Via: SIP/2.0/UDP 192.168.10.40:5060;branch=z9hG4bK1a7bc3cdf6e22598 Record-Route: <sip:192.168.10.1;lr=on;ftag=0d380f28344df9f2> From: "Ventas" <sip:112@192.168.10.1>;tag=0d380f28344df9f2 To: <sip:*700@192.168.10.1>;tag=as5aea7a9e Call-ID: f69f46f8461d45e0(a)192.168.10.40 CSeq: 55344 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Contact: <sip:*700@192.168.10.1:5070> Content-Type: application/sdp Content-Length: 285 v=0 o=root 9758 9759 IN IP4 192.168.10.1 s=session c=IN IP4 192.168.10.1 t=0 0 m=audio 15948 RTP/AVP 0 18 101 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - a=ptime:20 a=recvonly # U +0.000104 192.168.10.1:5060 -> 192.168.10.40:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.10.40:5060;branch=z9hG4bK1a7bc3cdf6e22598 Record-Route: <sip:192.168.10.1;lr=on;ftag=0d380f28344df9f2> From: "Ventas" <sip:112@192.168.10.1>;tag=0d380f28344df9f2 To: <sip:*700@192.168.10.1>;tag=as5aea7a9e Call-ID: f69f46f8461d45e0(a)192.168.10.40 CSeq: 55344 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Contact: <sip:*700@192.168.10.1:5070> Content-Type: application/sdp Content-Length: 285 v=0 o=root 9758 9759 IN IP4 192.168.10.1 s=session c=IN IP4 192.168.10.1 t=0 0 m=audio 15948 RTP/AVP 0 18 101 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - a=ptime:20 a=recvonly # U +0.054311 192.168.10.40:5060 -> 192.168.10.1:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.10.1;branch=z9hG4bK745a.fb2f15e.0 Via: SIP/2.0/UDP 192.168.10.1:5070;branch=z9hG4bK61abb915;rport=5070 Record-Route: <sip:192.168.10.1;lr=on;ftag=as6fb8efad> From: "Ventas" <sip:112@192.168.10.1>;tag=as6fb8efad To: <sip:112@192.168.10.1>;tag=368cbb40ae863e2a Call-ID: 3492c4a24c10596e6e3063c361c67eb9(a)192.168.10.1 CSeq: 102 INVITE User-Agent: Grandstream GXP2020 1.1.6.16 Contact: <sip:112@192.168.10.40:5060;transport=udp> Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE Content-Type: application/sdp Supported: replaces, timer Content-Length: 234 v=0 o=112 8000 8000 IN IP4 192.168.10.40 s=SIP Call c=IN IP4 192.168.10.40 t=0 0 m=audio 5004 RTP/AVP 0 101 a=sendrecv a=rtpmap:0 PCMU/8000 a=ptime:20 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-11 m=video 0 RTP/AVP 99 # U +0.000097 192.168.10.1:5060 -> 192.168.10.1:5070 SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.10.1:5070;branch=z9hG4bK61abb915;rport=5070 Record-Route: <sip:192.168.10.1;lr=on;ftag=as6fb8efad> From: "Ventas" <sip:112@192.168.10.1>;tag=as6fb8efad To: <sip:112@192.168.10.1>;tag=368cbb40ae863e2a Call-ID: 3492c4a24c10596e6e3063c361c67eb9(a)192.168.10.1 CSeq: 102 INVITE User-Agent: Grandstream GXP2020 1.1.6.16 Contact: <sip:112@192.168.10.40:5060;transport=udp> Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE Content-Type: application/sdp Supported: replaces, timer Content-Length: 234 I have openser and asterisk with realtime any ideas ? regards list rickygm

2 1

[Serusers] from header as append_hf() param
by caio 30 Dec '08

30 Dec '08

Hi all, Is it possible to add the current from header (%fu or $fu) or contact header as parameter of the append_hf textops function? I need to add a custom header like the following: append_hf("P-Asserted-Identity: \"Caller guy\" <%fu>); Result: ...P-Asserted-Identity: "Caller guy" <123(a)10.3.23.5>) There is an "append_urihf()" but it adds as prefix or suffix the R-URI address. Important, SER version 0.9.7. Regards, Claudio

1 0

[Serusers] get uri in module
by Netadmin Bensoft 30 Dec '08

30 Dec '08

Hello, I made a module and i want to get the uri from sip msg. How can i do this? What i need is the phone from uri or the uri (sip:1234@sip.sip.com) I've tried get_to(msg)->uri.s but it doesn't return the uri.. Thanks.

2 1

[Kamailio-Users] drop() and tm timers.
by Aurelien Grimaud 29 Dec '08

29 Dec '08

Hi, In my openser, I had to not relay any provisional which is < 180. I used drop in reply route to do this. No provisional < 180 is sent to caller. Unfortunately, dropping 100 seems to make the transaction module not disarming its fr_timer. The 180 has been waited for more time than my fr_timer so request failed and failure_route was called. In fact, there is no 180, only a 200 ok. Can anyone confirm that disarming timer is *not* done if 100 is dropped ? This is openser 1.2.1 Regards. Aurelien

3 10

[Kamailio-Users] "Failed" acc log when 183 Session Progress
by Samuel Muller 29 Dec '08

29 Dec '08

Hello all, I just have a little question about this thing : when I start a call, my Radius receives before the session is established a "failed" in its accounting log. If I move the setflag() for rad acc and rad failed acc (or one of each, then the other one), the "Start" disappear - but I get the Stop. How to not take acc in charge when there is a 183 Session Progress ? here is the radius acc log : Code: Accounting-Request Identifier: 102 Authentic: Z3z<16>^<230><251>i<233>[6Q<196><12><140><25> Attributes: Acct-Status-Type = Failed Service-Type = Sip-Session Sip-Response-Code = 183 Sip-Method = "<1>" Event-Timestamp = 1230128211 Sip-From-Tag = "a3addce43738cc27o0" Sip-To-Tag = "1c782477072" Acct-Session-Id = "10bdf568-2821ed73(a)192.168.1.7" Sip-Method = "INVITE" SER-From = "0170645745" SER-To = "0663128505" Sip-User-Digest-URI = "sip:0663128505@sip.720.fr<sip%3A0663128505(a)sip.720.fr> " Sip-Req-URI = "sip:0663128505@77.246.81.136:5060;transport=udp" Sip-Source-IP-Address = "87.90.4.63" Sip-Source-Port = "5060" NAS-Port = 5060 Acct-Delay-Time = 0 NAS-IP-Address = 192.168.60.9 the setflag() are here : if (is_method("INVITE")) { setflag(4); # flag "radius acc" setflag(5); # flag "radius failed acc" setflag(8); # flag "dialog" setflag(9); # flag "session timer" route(13); } the only place I found the related "183" taken in charge in the kamailio.cfg is here : onreply_route[2] { if (nat_uac_test("1")) { fix_nated_contact(); } if (isbflagset(14) && status =~ "(180|183|2[0-9][0-9])") #? branch flag nat { if (!search("^Content-Length:[ ]*0")) { force_rtp_proxy(); } } exit; } in the kamailio log for this same call : Dec 24 15:16:51 ser0 kamailio[7748]: DBG:core:parse_msg: SIP Reply (status): Dec 24 15:16:51 ser0 kamailio[7748]: DBG:core:parse_msg: version: <SIP/2.0> Dec 24 15:16:51 ser0 kamailio[7748]: DBG:core:parse_msg: status: <100> Dec 24 15:16:51 ser0 kamailio[7748]: DBG:core:parse_msg: reason: <Trying> Dec 24 15:16:51 ser0 kamailio[7748]: DBG:core:parse_headers: flags=2 Dec 24 15:16:51 ser0 kamailio[7748]: DBG:core:parse_via_param: found param type 232, <branch> = <z9hG4bKbe63.1eddc1f3.0>; state=16 Dec 24 15:16:51 ser0 kamailio[7748]: DBG:core:parse_via: end of header reached, state=5 Dec 24 15:16:51 ser0 kamailio[7748]: DBG:core:parse_headers: via found, flags=2 Dec 24 15:16:51 ser0 kamailio[7748]: DBG:core:parse_headers: this is the first via Dec 24 15:16:51 ser0 kamailio[7748]: DBG:core:receive_msg: After parse_msg... Dec 24 15:16:51 ser0 kamailio[7748]: DBG:core:grep_sock_info: checking if host==us: 13==13 && [77.246.81.132] == [77.246.81.132] Dec 24 15:16:51 ser0 kamailio[7748]: DBG:core:grep_sock_info: checking if port 5060 matches port 5060 Dec 24 15:16:51 ser0 kamailio[7748]: DBG:core:forward_reply: found module tm, passing reply to it Dec 24 15:16:51 ser0 kamailio[7748]: DBG:tm:t_check: start=0xffffffffffffffff Dec 24 15:16:51 ser0 kamailio[7748]: DBG:core:parse_headers: flags=22 Dec 24 15:16:51 ser0 kamailio[7748]: DBG:core:parse_via_param: found param type 235, <rport> = <5060>; state=6 Dec 24 15:16:51 ser0 kamailio[7748]: DBG:core:parse_via_param: found param type 234, <received> = <87.90.4.63>; state=6 Dec 24 15:16:51 ser0 kamailio[7748]: DBG:core:parse_via_param: found param type 232, <branch> = <z9hG4bK-8aeb8bb>; state=16 Dec 24 15:16:51 ser0 kamailio[7748]: DBG:core:parse_via: end of header reached, state=5 Dec 24 15:16:51 ser0 kamailio[7748]: DBG:core:parse_headers: via found, flags=22 Dec 24 15:16:51 ser0 kamailio[7748]: DBG:core:parse_headers: parse_headers: this is the second via Dec 24 15:16:51 ser0 kamailio[7748]: DBG:core:parse_to_param: tag=1c782477072 Dec 24 15:16:51 ser0 kamailio[7748]: DBG:core:parse_to: end of header reached, state=29 Dec 24 15:16:51 ser0 kamailio[7748]: DBG:core:parse_to: display={"0663128505"}, ruri={sip:0663128505@sip.720.fr<sip%3A0663128505(a)sip.720.fr>} Dec 24 15:16:51 ser0 kamailio[7748]: DBG:core:get_hdr_field: <To> [58]; uri=[sip:0663128505@sip.720.fr <sip%3A0663128505(a)sip.720.fr>] Dec 24 15:16:51 ser0 kamailio[7748]: DBG:core:get_hdr_field: to body ["0663128505" <sip:0663128505@sip.720.fr <sip%3A0663128505(a)sip.720.fr>>] Dec 24 15:16:51 ser0 kamailio[7748]: DBG:core:get_hdr_field: cseq <CSeq>: <102> <INVITE> Dec 24 15:16:51 ser0 kamailio[7748]: DBG:core:parse_headers: flags=8 Dec 24 15:16:51 ser0 kamailio[7748]: DBG:tm:t_reply_matching: hash 14059 label 1058856417 branch 0 Dec 24 15:16:51 ser0 kamailio[7748]: DBG:tm:t_reply_matching: REF_UNSAFE: after is 1 Dec 24 15:16:51 ser0 kamailio[7748]: DBG:tm:t_reply_matching: reply matched (T=0x7fcc45ebb090)! Dec 24 15:16:51 ser0 kamailio[7748]: DBG:tm:run_trans_callbacks: trans=0x7fcc45ebb090, callback type 2, id 1 entered Dec 24 15:16:51 ser0 kamailio[7748]: DBG:tm:t_check: end=0x7fcc45ebb090 Dec 24 15:16:51 ser0 kamailio[7748]: DBG:tm:reply_received: org. status uas=0, uac[0]=0 local=0 is_invite=1) Dec 24 15:16:51 ser0 kamailio[7748]: -NAT-ONREPLY----------------------------- Dec 24 15:16:51 ser0 kamailio[7748]: DBG:core:parse_headers: flags=80 Dec 24 15:16:51 ser0 kamailio[7748]: DBG:core:get_hdr_field: content_length=0 Dec 24 15:16:51 ser0 kamailio[7748]: DBG:core:get_hdr_field: found end of header Dec 24 15:16:51 ser0 kamailio[7748]: DBG:tm:t_should_relay_response: T_code=0, new_code=100 Dec 24 15:16:51 ser0 kamailio[7748]: DBG:tm:relay_reply: branch=0, save=0, relay=-1 Dec 24 15:16:51 ser0 kamailio[7748]: DBG:tm:set_timer: relative timeout is 60 Dec 24 15:16:51 ser0 kamailio[7748]: DBG:tm:insert_timer_unsafe: [1]: 0x7fcc45ebb2e0 (95) Dec 24 15:16:51 ser0 kamailio[7748]: DBG:tm:t_unref: UNREF_UNSAFE: after is 0 Dec 24 15:16:51 ser0 kamailio[7748]: DBG:core:destroy_avp_list: destroying list (nil) Dec 24 15:16:51 ser0 kamailio[7748]: DBG:core:receive_msg: cleaning up Dec 24 15:16:51 ser0 kamailio[7747]: DBG:core:parse_msg: SIP Reply (status): Dec 24 15:16:51 ser0 kamailio[7747]: DBG:core:parse_msg: version: <SIP/2.0> Dec 24 15:16:51 ser0 kamailio[7747]: DBG:core:parse_msg: status: <183> Dec 24 15:16:51 ser0 kamailio[7747]: DBG:core:parse_msg: reason: <Session Progress> Dec 24 15:16:51 ser0 kamailio[7747]: DBG:core:parse_headers: flags=2 Dec 24 15:16:51 ser0 kamailio[7747]: DBG:core:parse_via_param: found param type 232, <branch> = <z9hG4bKbe63.1eddc1f3.0>; state=16 Dec 24 15:16:51 ser0 kamailio[7747]: DBG:core:parse_via: end of header reached, state=5 Dec 24 15:16:51 ser0 kamailio[7747]: DBG:core:parse_headers: via found, flags=2 Dec 24 15:16:51 ser0 kamailio[7747]: DBG:core:parse_headers: this is the first via Dec 24 15:16:51 ser0 kamailio[7747]: DBG:core:receive_msg: After parse_msg... Dec 24 15:16:51 ser0 kamailio[7747]: DBG:core:grep_sock_info: checking if host==us: 13==13 && [77.246.81.132] == [77.246.81.132] Dec 24 15:16:51 ser0 kamailio[7747]: DBG:core:grep_sock_info: checking if port 5060 matches port 5060 Dec 24 15:16:51 ser0 kamailio[7747]: DBG:core:forward_reply: found module tm, passing reply to it Dec 24 15:16:51 ser0 kamailio[7747]: DBG:tm:t_check: start=0xffffffffffffffff Dec 24 15:16:51 ser0 kamailio[7747]: DBG:core:parse_headers: flags=22 Dec 24 15:16:51 ser0 kamailio[7747]: DBG:core:parse_via_param: found param type 235, <rport> = <5060>; state=6 Dec 24 15:16:51 ser0 kamailio[7747]: DBG:core:parse_via_param: found param type 234, <received> = <87.90.4.63>; state=6 Dec 24 15:16:51 ser0 kamailio[7747]: DBG:core:parse_via_param: found param type 232, <branch> = <z9hG4bK-8aeb8bb>; state=16 Dec 24 15:16:51 ser0 kamailio[7747]: DBG:core:parse_via: end of header reached, state=5 Dec 24 15:16:51 ser0 kamailio[7747]: DBG:core:parse_headers: via found, flags=22 Dec 24 15:16:51 ser0 kamailio[7747]: DBG:core:parse_headers: parse_headers: this is the second via Dec 24 15:16:51 ser0 kamailio[7747]: DBG:core:parse_to_param: tag=1c782477072 Dec 24 15:16:51 ser0 kamailio[7747]: DBG:core:parse_to: end of header reached, state=29 Dec 24 15:16:51 ser0 kamailio[7747]: DBG:core:parse_to: display={"0663128505"}, ruri={sip:0663128505@sip.720.fr<sip%3A0663128505(a)sip.720.fr>} Dec 24 15:16:51 ser0 kamailio[7747]: DBG:core:get_hdr_field: <To> [58]; uri=[sip:0663128505@sip.720.fr <sip%3A0663128505(a)sip.720.fr>] Dec 24 15:16:51 ser0 kamailio[7747]: DBG:core:get_hdr_field: to body ["0663128505" <sip:0663128505@sip.720.fr <sip%3A0663128505(a)sip.720.fr>>] Dec 24 15:16:51 ser0 kamailio[7747]: DBG:core:get_hdr_field: cseq <CSeq>: <102> <INVITE> Dec 24 15:16:51 ser0 kamailio[7747]: DBG:core:parse_headers: flags=8 Dec 24 15:16:51 ser0 kamailio[7747]: DBG:tm:t_reply_matching: hash 14059 label 1058856417 branch 0 Dec 24 15:16:51 ser0 kamailio[7747]: DBG:tm:t_reply_matching: REF_UNSAFE: after is 1 Dec 24 15:16:51 ser0 kamailio[7747]: DBG:tm:t_reply_matching: reply matched (T=0x7fcc45ebb090)! Dec 24 15:16:51 ser0 kamailio[7747]: DBG:tm:run_trans_callbacks: trans=0x7fcc45ebb090, callback type 2, id 1 entered Dec 24 15:16:51 ser0 kamailio[7747]: DBG:core:parse_headers: flags=8 Dec 24 15:16:51 ser0 kamailio[7747]: DBG:tm:t_check: end=0x7fcc45ebb090 Dec 24 15:16:51 ser0 kamailio[7747]: DBG:tm:reply_received: org. status uas=0, uac[0]=100 local=0 is_invite=1) Dec 24 15:16:51 ser0 kamailio[7747]: -NAT-ONREPLY----------------------------- Dec 24 15:16:51 ser0 kamailio[7747]: DBG:core:parse_headers: flags=80 Dec 24 15:16:51 ser0 kamailio[7747]: DBG:core:parse_headers: flags=ffffffffffffffff Dec 24 15:16:51 ser0 kamailio[7747]: DBG:core:get_hdr_field: content_length=293 Dec 24 15:16:51 ser0 kamailio[7747]: DBG:core:get_hdr_field: found end of header Dec 24 15:16:51 ser0 kamailio[7747]: DBG:nathelper:check_content_type: type <application/sdp> found valid Dec 24 15:16:51 ser0 kamailio[7747]: DBG:core:parse_headers: flags=40 Dec 24 15:16:51 ser0 kamailio[7747]: DBG:core:parse_to_param: tag=a3addce43738cc27o0 Dec 24 15:16:51 ser0 kamailio[7747]: DBG:core:parse_to: end of header reached, state=29 Dec 24 15:16:51 ser0 kamailio[7747]: DBG:core:parse_to: display={"0170645745"}, ruri={sip:0170645745@sip.720.fr<sip%3A0170645745(a)sip.720.fr>} Dec 24 15:16:51 ser0 kamailio[7747]: DBG:nathelper:force_rtp_proxy2_f: proxy reply: 35934 77.246.81.133 Dec 24 15:16:51 ser0 kamailio[7747]: DBG:tm:t_should_relay_response: T_code=0, new_code=183 Dec 24 15:16:51 ser0 kamailio[7747]: DBG:tm:relay_reply: branch=0, save=0, relay=0 Dec 24 15:16:51 ser0 kamailio[7747]: DBG:tm:run_trans_callbacks: trans=0x7fcc45ebb090, callback type 16, id 0 entered Dec 24 15:16:51 ser0 kamailio[7747]: DBG:dialog:run_dlg_callbacks: dialog=0x7fcc45ebc7c0, type=256 Dec 24 15:16:51 ser0 kamailio[7747]: DBG:sst:sst_dialog_response_fwded_CB: Dialog seen REPLY 183 Session Progress Dec 24 15:16:51 ser0 kamailio[7747]: DBG:core:parse_headers: flags=2000 Dec 24 15:16:51 ser0 kamailio[7747]: DBG:core:parse_headers: flags=ffffffffffffffff Dec 24 15:16:51 ser0 kamailio[7747]: DBG:core:clen_builder: content-length: 311 (311) Dec 24 15:16:51 ser0 kamailio[7747]: DBG:core:build_res_buf_from_sip_res: old size: 1027, new size: 983 Dec 24 15:16:51 ser0 kamailio[7747]: DBG:core:build_res_buf_from_sip_res: copied size: orig:1025, new: 981, rest: 2 msg= SIP/2.0 183 Session Progress^M Via: SIP/2.0/UDP 192.168.1.7:5060;rport=5060;received=87.90.4.63;branch=z9hG4bK-8aeb8bb^M From: "0170645745" <sip:0170645745@sip.720.fr <sip%3A0170645745(a)sip.720.fr>>;tag=a3addce43738cc27o0^M To: "0663128505" <sip:0663128505@sip.720.fr <sip%3A0663128505(a)sip.720.fr>>;tag=1c782477072^M Call-ID: 10bdf568-2821ed73(a)192.168.1.7^M CSeq: 102 INVITE^M Contact: < sip:61@77.246.81.136 <sip%3A61(a)77.246.81.136>>^M Record-Route: <sip:77.246.81.132;lr=on;ftag=a3addce43738cc27o0;nat=yes;did=17a.36b075d2>^M Supported: em,timer,replaces,path,resource-priority^M Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE^M Server: 720 DEGRES PSTN GW/v.5.40A.030.002^M Content-Type: application/sdp^M Content-Length: 311^M ^M v=0^M o=AudiocodesGW 782585440 782585110 IN IP4 77.246.81.136^M s=Phone-Call^M c=IN IP4 77.246.81.133^M t=0 0^M m=audio 35934 RTP/AVP 18 101^M a=rtpmap:18 G729/8000^M a=fmtp:18 annexb=yes^M a=rtpmap:101 telephone-event/ Dec 24 15:16:51 ser0 kamailio[7747]: DBG:core:_shm_resize: resize(0) called Dec 24 15:16:51 ser0 kamailio[7747]: DBG:tm:relay_reply: sent buf=0x7936d8: SIP/2.0 1..., shmem=0x7fcc45ebef00: SIP/2.0 1 Dec 24 15:16:51 ser0 kamailio[7747]: DBG:tm:run_trans_callbacks: trans=0x7fcc45ebb090, callback type 128, id 1 entered Dec 24 15:16:51 ser0 kamailio[7747]: DBG:core:parse_headers: flags=14000 Dec 24 15:16:51 ser0 kamailio[7747]: DBG:tm:run_trans_callbacks: trans=0x7fcc45ebb090, callback type 128, id 0 entered Dec 24 15:16:51 ser0 kamailio[7747]: DBG:dialog:next_state_dlg: dialog 0x7fcc45ebc7c0 changed from state 1 to state 2, due event 2 Dec 24 15:16:51 ser0 kamailio[7747]: DBG:tm:set_timer: relative timeout is 60 Dec 24 15:16:51 ser0 kamailio[7747]: DBG:tm:insert_timer_unsafe: [1]: 0x7fcc45ebb2e0 (96) Dec 24 15:16:51 ser0 kamailio[7747]: DBG:tm:t_unref: UNREF_UNSAFE: after is 0 Dec 24 15:16:51 ser0 kamailio[7747]: DBG:core:destroy_avp_list: destroying list (nil) Dec 24 15:16:51 ser0 kamailio[7747]: DBG:core:receive_msg: cleaning up Dec 24 15:16:51 ser0 kamailio[7753]: DBG:tm:utimer_routine: timer routine:4,tl=0x7fcc45ebb2b0 next=(nil), timeout=36400000 -- Samuel MULLER sml(a)720.fr

2 3

[Kamailio-Users] snmpstats error
by Stagg Shelton 28 Dec '08

28 Dec '08

I am planning an upgrade from openser 1.3.4 to kamailio 1.4.3, and I am having an issue starting kamailio with snmpstats enabled. I find the errors below in the kamailio syslog file. It looks like the root issue is a missing symbol, but I have not been able to figure out what provides the symbol. Openser 1.3.4 works fine on the same machine with essentially the same configuration that I am wanting to use for kamailio. The snmpstats.so module compiled without any errors, and is located in the /lib/ kamailio/modules/ directory. The system is fedora core 6 fully yum updated. Dec 24 14:24:26 sip-interop-c61-atl kamailio: ERROR:core:sr_load_module: could not open module <//lib/kamailio/ modules/snmpstats.so>: /usr/lib/libnetsnmpagent.so.10: undefined symbol: make_tempfile Dec 24 14:24:26 sip-interop-c61-atl kamailio: CRITICAL:core:yyerror: parse error in config file, line 57, column 13-14: failed to load module Dec 24 14:24:26 sip-interop-c61-atl kamailio: ERROR:core:set_mod_param_regex: no module matching snmpstats found | Dec 24 14:24:26 sip-interop-c61-atl kamailio: CRITICAL:core:yyerror: parse error in config file, line 142, column 20-21: Can't set module parameter Dec 24 14:24:26 sip-interop-c61-atl kamailio: ERROR:core:set_mod_param_regex: no module matching snmpstats found | Dec 24 14:24:26 sip-interop-c61-atl kamailio: CRITICAL:core:yyerror: parse error in config file, line 143, column 20-21: Can't set module parameter Dec 24 14:24:26 sip-interop-c61-atl kamailio: ERROR:core:set_mod_param_regex: no module matching snmpstats found | Dec 24 14:24:26 sip-interop-c61-atl kamailio: CRITICAL:core:yyerror: parse error in config file, line 144, column 20-21: Can't set module parameter Dec 24 14:24:26 sip-interop-c61-atl kamailio: ERROR:core:set_mod_param_regex: no module matching snmpstats found | Dec 24 14:24:26 sip-interop-c61-atl kamailio: CRITICAL:core:yyerror: parse error in config file, line 145, column 20-21: Can't set module parameter Dec 24 14:24:26 sip-interop-c61-atl kamailio: ERROR:core:main: bad config file (5 errors) Has anyone seen this error, or something similar? Thank You Stagg Shelton www.sheltonjohns.com

3 3

[Kamailio-Users] sub:Query on PUA
by skumar453＠gmail.com 28 Dec '08

28 Dec '08

Hi All, HAPPY CHRISTMAS , I am working on PUA module.I am running PUA as Apllication server.I have registered ALICE in a client which doesn't have presence support (OpenIC client) and BOB in UCTIMSCLIENT which has presence support.And i am invoking SUBSCRIBE message by a script file to know the presence of BOB to ALICE. When the status of BOB is changed,NOTIFY is getting Terminated at I-CSCF. ERROR i am getting is : "406 Initial Request Method not allowed atthe I-CSCF". According to traces while registration flow is as follows: FLOW 1: PUA------>i-cscf------>s-cscf. But actually the flow should be: FLOW 2: PUA------>p-cscf------>s-cscf. I have enabled outbound proxy server in configuration file to get FLOW 2.But,the flow is not changed. Kindly let me know ,how to get NOTIFY message when status of BOB is changed. Thanks in Advance.

2 1

Re: [Kamailio-Users] [Kamailio-Devel] new module: qos
by Daniel-Constantin Mierla 28 Dec '08

28 Dec '08

Thanks Ovidiu, readme is online at: http://kamailio.org/docs/modules/devel/qos.html Is the module keeping track of all session negotiated, or is stores the last one (used)? Happy holidays! Daniel On 12/23/08 23:05, Ovidiu Sas wrote: > Hello, > > QoS is an new module that can be used to track per dialog SDP sessions. > The QoS module is sitting on top of the dialog module and provides an > API to be used by other module. > The QoS module does not provide any scripting functionality (it is a > passive module). > See the module documentation for more informations. > > SDP session(s) can be inspected via the dialog dlg_list_ctx MI > interface command: > dialog:: hash=3732:573385728 > state:: 4 > timestart:: 1230068558 > timeout:: 1009 > callid:: d3d816cce3e24a19b937b56e4689e524 > from_uri:: sip:111111111@10.11.10.63 > from_tag:: 8c85c079 > caller_contact:: sip:111111111@10.11.128.129 > caller_cseq:: 100 > caller_route_set:: > caller_bind_addr:: udp:10.11.10.63:5060 > to_uri:: sip:222222222@10.11.10.63 > to_tag:: 43FED9C4-20CF > callee_contact:: sip:222222222@10.111.3.241:5060 > callee_cseq:: 100 > callee_route_set:: > callee_bind_addr:: udp:10.11.10.63:5060 > context:: > qos:: negotiated_sdp > sdp:: m_dir=1 m_id=1 method=INVITE cseq=100 > negotiation=1 > session:: callee cnt_disp= bw_type= > bw_width= streams=2 > stream:: 1 media=video > IP=10.111.3.241 port=0 transport=RTP/AVP payloads_num=0 > stream:: 0 media=audio > IP=10.111.3.241 port=17240 transport=RTP/AVP payloads_num=3 > payload:: 2 rtpmap=100 > codec=X-NSE > payload:: 1 rtpmap=101 > codec=telephone-event > payload:: 0 rtpmap=0 codec=PCMU > session:: caller cnt_disp= bw_type=AS > bw_width=400 streams=2 > stream:: 1 media=video > IP=10.11.128.129 port=22804 transport=RTP/AVP payloads_num=2 > payload:: 1 rtpmap=34 codec=H263 > payload:: 0 rtpmap=107 > codec=H263-1998 > stream:: 0 media=audio > IP=10.11.128.129 port=22800 transport=RTP/AVP payloads_num=12 > payload:: 11 > rtpmap=112 codec=iLBC > payload:: 10 > rtpmap=100 codec=AMR > payload:: 9 rtpmap=13 codec=CN > payload:: 8 rtpmap=101 > codec=telephone-event > payload:: 7 rtpmap=111 > codec=G726-40 > payload:: 6 rtpmap=110 > codec=G726-32 > payload:: 5 rtpmap=109 > codec=G726-24 > payload:: 4 rtpmap=108 > codec=G726-16 > payload:: 3 rtpmap=4 codec=G723 > payload:: 2 rtpmap=18 codec=G729 > payload:: 1 rtpmap=0 codec=PCMU > payload:: 0 rtpmap=8 codec=PCMA > > > > Regards, > Ovidiu Sas > > _______________________________________________ > Devel mailing list > Devel(a)lists.kamailio.org > http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel > > -- Daniel-Constantin Mierla http://www.asipto.com

2 1

[Kamailio-Users] Merry Christmas and Happy New Year 2009!
by Daniel-Constantin Mierla 24 Dec '08

24 Dec '08

Hello, I wish everyone Merry Christmas and Happy New Year 2009! Day by day, we ended another year. 2008 was full of events, starting with one major release and six minor releases, participation to workshops and conferences wordlwide, adoption in new production environments and acknowledgement of running platforms with millions of users and billions of routed minutes/month using Kamailio (OpenSER), check the News archive at: http://www.kamailio.org There were sad events as well, including the hijacking of the old domain name after the rename in Kamailio, still the source forge project goes on, with same name, proving the genuine openser project: https://sourceforge.net/projects/openser/ We maintained release 1.3.x series, last being 1.3.4, which still keeps the old name and is available at: http://www.openser-project.org/mos/view/News/NewsItem/OpenSER-v1.3.4-Releas… Life is going on, since the latest major release, version 1.4.0, the project boosted in new features, a summary of what is new since then is available here: http://www.kamailio.org/dokuwiki/doku.php/features:new-in-1.5.x An important share of effort was directed to clean the code and improve the stability and performance, a proof of maturity and the need to make the maintenance of the project easier and open for new comers. Lot of documentation was added in doxygen format inside the source code, Devel Guide was published, new developers can start new easier to enhance the application. Reference moment for the future was the launch of SIP Router project in November - a concentration of many people with great SIP and VoIP expertise, backed up by huge programming experience in this field. This came to strengthen the development workforce, to ensure the reliability, to remove the doubts of what projects is better now or is going to develop better in the future. http://sip-router.org So, 2009 is an year that announces already great achievements to be done in its first half: - 1st Quarter - release of Kamailio (OpenSER) 1.5.0 - 2nd Quarter - release of SIP Router project as stable version - dedicated meeting to celebrate the first operational SIP Router and draw future directions With the release of SIP Router project, everyone gets access to the features provided by Kamailio (OpenSER), SIP Express Router and OpenIMSCore projects: http://sip-router.org/benefits/ Looking forward to a fruitful 2009! Daniel -- Daniel-Constantin Mierla http://www.asipto.com

2 1

[Kamailio-Users] how to bild "pidf" for network elements
by skumar453＠gmail.com 22 Dec '08

22 Dec '08

Hi all I am developing presence network agent(PNA)..IT collects the presence information from the core network elements like Serving-call session control function(scscf)..and home subscriber server(HSS). and it will construct the publish message and send it to the Presence server(PS). here my doubt is what should be the content in the publish message for network presence? can any one suggest how to do it ? and can anyone let me know, whether there are any RFC or Specification for constructing PUBLISH message for network elements? thank you in advance suresh

3 2

[Kamailio-Users] Using a b2bua as a prepaid box
by Luciano Afranllie 22 Dec '08

22 Dec '08

Hi everybody, I am experimenting trying to build a prepaid solution using prepaid extension for RADIUS (IETF draft). My current test bed is Kamailio as SIP proxy/registrar, asterisk as PSTN gateway, sippy b2bua and a freeRadius server. What I am thinking about is to split users in groups (prepaid, postpaid and suspended, for example) and to send all calls from prepaid users to the b2bua. The b2bua will have the prepaid client logic to enforce balance usage and drop calls. I am new in this area so I will appreciate a lot your feedback about what is the best way to do this. - Regarding groups. Is it worth to use radius for this or can I just use kamailio groups? - Regarding sending prepaid users calls to b2bua. It is a nice solution in kamailio to check user group and if it belongs to prepaid group forward the call to b2bua and b2bua forward the call again to kamailio in order to make the final routing? How should I identify the call has already been sent to the b2bua and is coming again to kamailio, just using the source host, or there is a better way? Thanks for your time. L:uciano

2 1

[Kamailio-Users] dns updates
by Daniel-Constantin Mierla 21 Dec '08

21 Dec '08

Hello, there will be some DNS updates to kamailio.org domain during this weekend, so there might be some outages until the DNS propagates. You can safely use kamailio.net to browse the web all the time. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

1 1

[Kamailio-Users] Fw: Help!! Delay in Invite with Authentication
by Rosario Pingaro 21 Dec '08

21 Dec '08

i am helping krunal debug this issue. The log from the router seems fine, no dealy in any other kind of messages. As the packets leave the router after 15ms they reach the proxy. Logging the router we get that the new invite is sent with delay, Is it possible that the router has some problem preparing the digest parameters? The very strange think is that the same router with the same config changing only the default proxy and letting it to point to a old SER config that does the invita auth by the same way, we don't get any delay. regards Rosario Pingaro D. Lgs 196/2003 Il presente messaggio contiene informazioni confidenziali, indirizzate esclusivamente alle persone sopra indicate. Se il ricevente non è tra dette persone, non dovrà intraprendere alcuna azione, tipo copia, stampa o trasmettere il suo contenuto a terzi ed i relativi allegati, ma solo informare il mittente dell'errore e cancellare il messaggio. Il mittente dovrà, altresì, accertarsi che gli allegati non contengano virus prima di aprirli. > ----- Original Message ----- > From: "Daniel-Constantin Mierla" <miconda(a)gmail.com> > To: "Krunal Patel" <krunal.lists(a)gmail.com> > Cc: <users(a)lists.kamailio.org> > Sent: Saturday, December 20, 2008 10:20 AM > Subject: Re: [Kamailio-Users] Help!! Delay in Invite with Authentication > > >> Hello, >> >> On 12/19/08 15:40, Krunal Patel wrote: >>> Hi, >>> >>> I am using openser 1.2.3. >>> >>> From a router calls comes to openser. >>> Router is PATTON 4960. >>> I am using domain name to send calls to openser. >>> >>> First invite comes to openser & openser sends 407 to the router & then >>> getting ACK from the router to openser. >>> >>> Now the invite with authentication comes after almost 10 to 11 sec >>> Since ACK comes to openser. >> looks being related to the client. Can you check the logs of the router? >> Might be something with the DNS, responding slow. >> >> Also, if you can plug the router in a hub you can check when the >> messages are sent and when they reach the sip proxy, being able to see >> where is the issue. >> >> Cheers, >> Daniel >> >>> >>> Here is the trace: >>> # >>> U 2008/12/19 12:24:24.374228 XXX.XXX.XXX.XXX:5060 -> >>> YYY.YYY.YYY.YYY:5060 >>> INVITE sip:[TO_NUMBER]@[EMAIL PROTECTED] SIP/2.0. >>> Via: SIP/2.0/UDP XXX.XXX.XXX.XXX:5060;branch=z9hG4bK227032cab. >>> Max-Forwards: 70. >>> Content-Length: 341. >>> To: sip:[TO_NUMBER]@[EMAIL PROTECTED]. >>> From: sip:[FROM_NUMBER]@[EMAIL PROTECTED];tag=72a0c76ae3d477c. >>> ... >>> # >>> U 2008/12/19 12:24:24.374544 YYY.YYY.YYY.YYY:5060 -> >>> XXX.XXX.XXX.XXX:5060 >>> SIP/2.0 407 Proxy Authentication Required. >>> Via: SIP/2.0/UDP >>> XXX.XXX.XXX.XXX:5060;branch=z9hG4bK227032cab;rport=5060. >>> To: sip:[TO_NUMBER]@[EMAIL >>> PROTECTED];tag=b802e73ab92fec121a4f880263d541a3.7575. >>> From: sip:[FROM_NUMBER]@[EMAIL PROTECTED];tag=72a0c76ae3d477c. >>> ... >>> >>> # >>> U 2008/12/19 12:24:24.407646 XXX.XXX.XXX.XXX:5060 -> >>> YYY.YYY.YYY.YYY:5060 >>> ACK sip:[TO_NUMBER]@[EMAIL PROTECTED] SIP/2.0. >>> Via: SIP/2.0/UDP XXX.XXX.XXX.XXX:5060;branch=z9hG4bK227032cab. >>> Max-Forwards: 70. >>> Content-Length: 0. >>> To: sip:[TO_NUMBER]@[EMAIL >>> PROTECTED];tag=b802e73ab92fec121a4f880263d541a3.7575. >>> Route: <sip:[EMAIL PROTECTED]:5060;lr>. >>> .... >>> >>> >>> # >>> U 2008/12/19 12:24:35.667448 XXX.XXX.XXX.XXX:5060 -> >>> YYY.YYY.YYY.YYY:5060 >>> INVITE sip:[TO_NUMBER]@[EMAIL PROTECTED] SIP/2.0. >>> Via: SIP/2.0/UDP XXX.XXX.XXX.XXX:5060;branch=z9hG4bK3362d177f. >>> Max-Forwards: 70. >>> Content-Length: 341. >>> To: sip:[TO_NUMBER]@[EMAIL PROTECTED]. >>> From: sip:[FROM_NUMBER]@[EMAIL PROTECTED];tag=72a0c76ae3d477c. >>> Route: <sip:[EMAIL PROTECTED]:5060;lr>. >>> ... >>> >>> U 2008/12/19 12:24:35.692576 YYY.YYY.YYY.YYY:5060 -> >>> ZZZ.ZZZ.ZZZ.ZZZ:5060 >>> INVITE sip:[TO_NUMBER]@ZZZ.ZZZ.ZZZ.ZZZ:5060;transport=udp SIP/2.0. >>> Record-Route: <sip:[TO_NUMBER]@[EMAIL >>> PROTECTED]:5060;ftag=72a0c76ae3d477c;lr=on>. >>> Via: SIP/2.0/UDP YYY.YYY.YYY.YYY;branch=z9hG4bK32dd.6cc062c5.0. >>> Via: SIP/2.0/UDP >>> XXX.XXX.XXX.XXX:5060;rport=5060;branch=z9hG4bK3362d177f. >>> Max-Forwards: 69. >>> Content-Length: 341. >>> To: sip:[TO_NUMBER]@[EMAIL PROTECTED]. >>> From: sip:[FROM_NUMBER]@[EMAIL PROTECTED];tag=72a0c76ae3d477c. >>> ... >>> >>> U 2008/12/19 12:24:35.731432 ZZZ.ZZZ.ZZZ.ZZZ:5060 -> >>> YYY.YYY.YYY.YYY:5060 >>> SIP/2.0 100 Trying. >>> Call-ID: 1c00f084ccd0232ad5ab638dc6a7ccfd@[EMAIL PROTECTED]. >>> CSeq: 1965370819 INVITE. >>> From: sip:[FROM_NUMBER]@[EMAIL PROTECTED];tag=72a0c76ae3d477c. >>> .... >>> >>> >>> U 2008/12/19 12:24:35.849714 ZZZ.ZZZ.ZZZ.ZZZ:5060 -> >>> YYY.YYY.YYY.YYY:5060 >>> SIP/2.0 183 Session Progress. >>> Call-ID: 1c00f084ccd0232ad5ab638dc6a7ccfd@[EMAIL PROTECTED]. >>> CSeq: 1965370819 INVITE. >>> From: sip:[FROM_NUMBER]@[EMAIL PROTECTED];tag=72a0c76ae3d477c. >>> To: sip:[TO_NUMBER]@[EMAIL PROTECTED];tag=86f125f633683d0. >>> ... >>> >>> # >>> U 2008/12/19 12:24:35.849961 YYY.YYY.YYY.YYY:5060 -> >>> XXX.XXX.XXX.XXX:5060 >>> SIP/2.0 183 Session Progress. >>> Call-ID: 1c00f084ccd0232ad5ab638dc6a7ccfd@[EMAIL PROTECTED]. >>> CSeq: 1965370819 INVITE. >>> From: sip:[FROM_NUMBER]@[EMAIL PROTECTED];tag=72a0c76ae3d477c. >>> To: sip:[TO_NUMBER]@[EMAIL PROTECTED];tag=86f125f633683d0. >>> >>> >>> Can anybody help me to trobleshoot the issue? >>> >>> Thanks in Advance!! >>> >>> -- >>> Krunal patel >>> >>> >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Users mailing list >>> Users(a)lists.kamailio.org >>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users >>> >> >> -- >> Daniel-Constantin Mierla >> http://www.asipto.com >> >> >> _______________________________________________ >> Users mailing list >> Users(a)lists.kamailio.org >> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users >> >> >

2 5

[Serusers] error in acc_radius in User-Name AVP - ser rel_2_0_0
by Tomasz Zieleniewski 20 Dec '08

20 Dec '08

Hi, There is an error in acc_radius module when SER sends first accounting request corresponding to invite the User-Name AVP is taken as the "user" parameter in the Authorization header field, which is the correct behaviour. Acct-Session-Id = "Njg1M2M4NzE0NzAyZTIwZjcyOWNhMzIyMGVlY2RiNmQ." Sip-To-Tag = "0234593C-494D655A00008C74-40C0B950" SER-From = "\"Tomasz Zieleniewski\"<sip:tzl@sip.rd.touk.pl<sip%3Atzl(a)sip.rd.touk.pl> >;tag=815fbd6e" SER-Flags = 140509184 SER-Original-Request-ID = "sip:test@sip.rd.touk.pl<sip%3Atest(a)sip.rd.touk.pl> " Sip-Method = "INVITE" Sip-Cseq = 2 Sip-Translated-Request-ID = "sip:announcement@212.180.179.42:7160" Sip-Source-IP-Address = 192.168.1.132 Sip-From-Tag = "815fbd6e" SER-To = "\"test\"<sip:test@sip.rd.touk.pl<sip%3Atest(a)sip.rd.touk.pl> >;tag=0234593C-494D655A00008C74-40C0B950" SER-Digest-Username = "tzl" SER-Request-Timestamp = 1229808986 Calling-Station-Id = "sip:tzl@sip.rd.touk.pl<sip%3Atzl(a)sip.rd.touk.pl> " Sip-Source-Port = 5499 SER-Digest-Realm = "touk.pl" Sip-Response-Code = 200 Called-Station-Id = "sip:test@sip.rd.touk.pl<sip%3Atest(a)sip.rd.touk.pl> " SER-Response-Timestamp = 1229808986 Acct-Status-Type = Start Service-Type = IAPP-Register User-Name = "tzl(a)touk.pl" NAS-Port = 5060 Acct-Delay-Time = 0 NAS-IP-Address = 127.0.0.1 When there is another accounting request for instance when there is session termination by BYE request User-Name AVP is equal to the "From" Header when it shouldn't because it should be used if there was no authentication. Acct-Session-Id = "Njg1M2M4NzE0NzAyZTIwZjcyOWNhMzIyMGVlY2RiNmQ." Sip-To-Tag = "0234593C-494D655A00008C74-40C0B950" SER-From = "\"Tomasz Zieleniewski\"<sip:tzl@sip.rd.touk.pl<sip%3Atzl(a)sip.rd.touk.pl> >;tag=815fbd6e" SER-Flags = 140509184 SER-Original-Request-ID = "sip:announcement@212.180.179.42:7160" Sip-Method = "BYE" Sip-Cseq = 3 Sip-Translated-Request-ID = "sip:announcement@212.180.179.42:7160" Sip-Source-IP-Address = 192.168.1.132 Sip-From-Tag = "815fbd6e" SER-To = "\"test\"<sip:test@sip.rd.touk.pl<sip%3Atest(a)sip.rd.touk.pl> >;tag=0234593C-494D655A00008C74-40C0B950" SER-Request-Timestamp = 1229808992 Calling-Station-Id = "sip:tzl@sip.rd.touk.pl<sip%3Atzl(a)sip.rd.touk.pl> " Sip-Source-Port = 5499 Sip-Response-Code = 200 Called-Station-Id = "sip:test@sip.rd.touk.pl<sip%3Atest(a)sip.rd.touk.pl> " SER-Response-Timestamp = 1229808992 Acct-Status-Type = Stop Service-Type = IAPP-Register User-Name = "tzl(a)sip.rd.touk.pl" NAS-Port = 5060 Acct-Delay-Time = 0 NAS-IP-Address = 127.0.0.1 Kind regards Tomasz Zieleniewski

1 0

[Kamailio-Users] Kamailio 1.4.2 : Weird Retransmission
by Aurelien Grimaud 20 Dec '08

20 Dec '08

Hi, I am using kamailio 1.4.2 and testing it with sipp. one sipp is client a uac (port 5066), the other is a uas (port 5063). kamailio is using 5060. I am generating 100 calls per second for 1000 calls and message were retransmitted 4 times. Here is a tcpdump of sip packets. Can anyone tell me why there is an INVITE retransmission at 16:16:38.627198 though the ACK for invite was received at 16:16:38.126096 ? Is there a known problem with retransmission timers ? 16:16:38.120384 IP 192.168.168.33.5066 > 192.168.168.33.5060: SIP, length: 579 E.._..@.@.f....!...!.....K..INVITE sip:otest@testg5 SIP/2.0 Via: SIP/2.0/UDP 127.0.0.1:5066;branch=z9hG4bK-23096-730-1 From: sipp <sip:730-23096-127.0.0.1@127.0.0.1:5066>;tag=23096SIPpTag09730 To: sut <sip:otest@testg5> Call-ID: 730-23096-127.0.0.1 CSeq: 1 INVITE Contact: sip:sipp@127.0.0.1:5066 Max-Forwards: 70 Expires: 180 Subject: Performance Test Content-Type: application/sdp Content-Length: 188 v=0 o=user1 53655765 2353687637 IN IP4 127.0.0.1 s=- c=IN IP4 127.0.0.1 t=0 0 m=audio 8925 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-11,16 16:16:38.123426 IP 192.168.168.33.5060 > 192.168.168.33.5066: SIP, length: 325 E..a..@.@.g....!...!.....M..SIP/2.0 100 Giving a try Via: SIP/2.0/UDP 127.0.0.1:5066;branch=z9hG4bK-23096-730-1;received=192.168.168.33 From: sipp <sip:730-23096-127.0.0.1@127.0.0.1:5066>;tag=23096SIPpTag09730 To: sut <sip:otest@testg5> Call-ID: 730-23096-127.0.0.1 CSeq: 1 INVITE Server: Kamailio (1.4.2-notls (i386/linux)) Content-Length: 0 16:16:38.123554 IP 192.168.168.33.5060 > 192.168.168.33.5063: SIP, length: 731 E.....@.@.fZ...!...!........INVITE sip:otest@testg5 SIP/2.0 Record-Route: <sip:192.168.168.33;lr=on;ftag=23096SIPpTag09730> Via: SIP/2.0/UDP 192.168.168.33;branch=z9hG4bKcb7d.7c08af34.0 Via: SIP/2.0/UDP 127.0.0.1:5066;received=192.168.168.33;branch=z9hG4bK-23096-730-1 From: sipp <sip:730-23096-127.0.0.1@127.0.0.1:5066>;tag=23096SIPpTag09730 To: sut <sip:otest@testg5> Call-ID: 730-23096-127.0.0.1 CSeq: 1 INVITE Contact: sip:sipp@127.0.0.1:5066 Max-Forwards: 69 Expires: 180 Subject: Performance Test Content-Type: application/sdp Content-Length: 188 v=0 o=user1 53655765 2353687637 IN IP4 127.0.0.1 s=- c=IN IP4 127.0.0.1 t=0 0 m=audio 8925 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-11,16 16:16:38.123830 IP 192.168.168.33.5063 > 192.168.168.33.5060: SIP, length: 451 E.....@.@.gz...!...!.......pSIP/2.0 180 Ringing Via: SIP/2.0/UDP 192.168.168.33;branch=z9hG4bKcb7d.7c08af34.0, SIP/2.0/UDP 127.0.0.1:5066;received=192.168.168.33;branch=z9hG4bK-23096-730-1 From: sipp <sip:730-23096-127.0.0.1@127.0.0.1:5066>;tag=23096SIPpTag09730 To: sut <sip:otest@testg5>;tag=17278SIPpTag01696 Call-ID: 730-23096-127.0.0.1 CSeq: 1 INVITE Record-Route: <sip:192.168.168.33;lr=on;ftag=23096SIPpTag09730> Contact: <sip:127.0.0.1:5063> Content-Length: 0 16:16:38.124169 IP 192.168.168.33.5060 > 192.168.168.33.5066: SIP, length: 393 E.....@.@.g....!...!.......6SIP/2.0 180 Ringing Via: SIP/2.0/UDP 127.0.0.1:5066;received=192.168.168.33;branch=z9hG4bK-23096-730-1 From: sipp <sip:730-23096-127.0.0.1@127.0.0.1:5066>;tag=23096SIPpTag09730 To: sut <sip:otest@testg5>;tag=17278SIPpTag01696 Call-ID: 730-23096-127.0.0.1 CSeq: 1 INVITE Record-Route: <sip:192.168.168.33;lr=on;ftag=23096SIPpTag09730> Contact: <sip:127.0.0.1:5063> Content-Length: 0 16:16:38.124326 IP 192.168.168.33.5063 > 192.168.168.33.5060: SIP, length: 634 E.....@.@.f....!...!.......'SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.168.33;branch=z9hG4bKcb7d.7c08af34.0, SIP/2.0/UDP 127.0.0.1:5066;received=192.168.168.33;branch=z9hG4bK-23096-730-1 From: sipp <sip:730-23096-127.0.0.1@127.0.0.1:5066>;tag=23096SIPpTag09730 To: sut <sip:otest@testg5>;tag=17278SIPpTag01696 Call-ID: 730-23096-127.0.0.1 CSeq: 1 INVITE Record-Route: <sip:192.168.168.33;lr=on;ftag=23096SIPpTag09730> Contact: <sip:127.0.0.1:5063> Content-Type: application/sdp Content-Length: 153 v=0 o=user1 53655765 2353687637 IN IP4 127.0.0.1 s=- c=IN IP4 127.0.0.1 t=0 0 m=audio 6004 RTP/AVP 0 8 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 16:16:38.124883 IP 192.168.168.33.5060 > 192.168.168.33.5066: SIP, length: 581 E..a..@.@.f....!...!.....M..SIP/2.0 200 OK Via: SIP/2.0/UDP 127.0.0.1:5066;received=192.168.168.33;branch=z9hG4bK-23096-730-1 From: sipp <sip:730-23096-127.0.0.1@127.0.0.1:5066>;tag=23096SIPpTag09730 To: sut <sip:otest@testg5>;tag=17278SIPpTag01696 Call-ID: 730-23096-127.0.0.1 CSeq: 1 INVITE Record-Route: <sip:192.168.168.33;lr=on;ftag=23096SIPpTag09730> Contact: <sip:192.168.168.33:5063> Content-Type: application/sdp Content-Length: 153 v=0 o=user1 53655765 2353687637 IN IP4 127.0.0.1 s=- c=IN IP4 127.0.0.1 t=0 0 m=audio 6004 RTP/AVP 0 8 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 16:16:38.125532 IP 192.168.168.33.5066 > 192.168.168.33.5060: SIP, length: 427 E.....@.@.g....!...!.......XACK sip:192.168.168.33:5063 SIP/2.0 Via: SIP/2.0/UDP 127.0.0.1:5066;branch=z9hG4bK-23096-730-11 From: sipp <sip:730-23096-127.0.0.1@127.0.0.1:5066>;tag=23096SIPpTag09730 To: sut <sip:otest@testg5>;tag=17278SIPpTag01696 Route: <sip:192.168.168.33;lr=on;ftag=23096SIPpTag09730> Call-ID: 730-23096-127.0.0.1 CSeq: 1 INVITE Contact: sip:sipp@127.0.0.1:5066 Max-Forwards: 70 Subject: Performance Test Content-Length: 0 16:16:38.126096 IP 192.168.168.33.5060 > 192.168.168.33.5063: SIP, length: 521 E..%..@.@.g,...!...!........ACK sip:192.168.168.33:5063 SIP/2.0 Record-Route: <sip:192.168.168.33;lr=on;ftag=23096SIPpTag09730> Via: SIP/2.0/UDP 192.168.168.33;branch=z9hG4bKcb7d.7c08af34.2 Via: SIP/2.0/UDP 127.0.0.1:5066;received=192.168.168.33;branch=z9hG4bK-23096-730-11 From: sipp <sip:730-23096-127.0.0.1@127.0.0.1:5066>;tag=23096SIPpTag09730 To: sut <sip:otest@testg5>;tag=17278SIPpTag01696 Call-ID: 730-23096-127.0.0.1 CSeq: 1 INVITE Contact: sip:sipp@127.0.0.1:5066 Max-Forwards: 69 Subject: Performance Test Content-Length: 0 16:16:38.627198 IP 192.168.168.33.5060 > 192.168.168.33.5063: SIP, length: 731 E.....@.@.fZ...!...!........INVITE sip:otest@testg5 SIP/2.0 Record-Route: <sip:192.168.168.33;lr=on;ftag=23096SIPpTag09730> Via: SIP/2.0/UDP 192.168.168.33;branch=z9hG4bKcb7d.7c08af34.0 Via: SIP/2.0/UDP 127.0.0.1:5066;received=192.168.168.33;branch=z9hG4bK-23096-730-1 From: sipp <sip:730-23096-127.0.0.1@127.0.0.1:5066>;tag=23096SIPpTag09730 To: sut <sip:otest@testg5> Call-ID: 730-23096-127.0.0.1 CSeq: 1 INVITE Contact: sip:sipp@127.0.0.1:5066 Max-Forwards: 69 Expires: 180 Subject: Performance Test Content-Type: application/sdp Content-Length: 188 v=0 o=user1 53655765 2353687637 IN IP4 127.0.0.1 s=- c=IN IP4 127.0.0.1 t=0 0 m=audio 8925 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-11,16 16:16:38.627677 IP 192.168.168.33.5063 > 192.168.168.33.5060: SIP, length: 474 E.....@.@.gc...!...!........SIP/2.0 180 Ringing Via: SIP/2.0/UDP 192.168.168.33;branch=z9hG4bKcb7d.7c08af34.2, SIP/2.0/UDP 127.0.0.1:5066;received=192.168.168.33;branch=z9hG4bK-23096-730-11 From: sipp <sip:730-23096-127.0.0.1@127.0.0.1:5066>;tag=23096SIPpTag09730 To: sut <sip:otest@testg5>;tag=17278SIPpTag01696;tag=17278SIPpTag01696 Call-ID: 730-23096-127.0.0.1 CSeq: 1 INVITE Record-Route: <sip:192.168.168.33;lr=on;ftag=23096SIPpTag09730> Contact: <sip:127.0.0.1:5063> Content-Length: 0 16:16:38.627970 IP 192.168.168.33.5060 > 192.168.168.33.5066: SIP, length: 416 E.....@.@.g....!...!.......MSIP/2.0 180 Ringing Via: SIP/2.0/UDP 127.0.0.1:5066;received=192.168.168.33;branch=z9hG4bK-23096-730-11 From: sipp <sip:730-23096-127.0.0.1@127.0.0.1:5066>;tag=23096SIPpTag09730 To: sut <sip:otest@testg5>;tag=17278SIPpTag01696;tag=17278SIPpTag01696 Call-ID: 730-23096-127.0.0.1 CSeq: 1 INVITE Record-Route: <sip:192.168.168.33;lr=on;ftag=23096SIPpTag09730> Contact: <sip:127.0.0.1:5063> Content-Length: 0 16:16:39.642356 IP 192.168.168.33.5060 > 192.168.168.33.5063: SIP, length: 731 E.....@.@.fZ...!...!........INVITE sip:otest@testg5 SIP/2.0 Record-Route: <sip:192.168.168.33;lr=on;ftag=23096SIPpTag09730> Via: SIP/2.0/UDP 192.168.168.33;branch=z9hG4bKcb7d.7c08af34.0 Via: SIP/2.0/UDP 127.0.0.1:5066;received=192.168.168.33;branch=z9hG4bK-23096-730-1 From: sipp <sip:730-23096-127.0.0.1@127.0.0.1:5066>;tag=23096SIPpTag09730 To: sut <sip:otest@testg5> Call-ID: 730-23096-127.0.0.1 CSeq: 1 INVITE Contact: sip:sipp@127.0.0.1:5066 Max-Forwards: 69 Expires: 180 Subject: Performance Test Content-Type: application/sdp Content-Length: 188 v=0 o=user1 53655765 2353687637 IN IP4 127.0.0.1 s=- c=IN IP4 127.0.0.1 t=0 0 m=audio 8925 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-11,16 16:16:39.642587 IP 192.168.168.33.5063 > 192.168.168.33.5060: SIP, length: 474 E.....@.@.gc...!...!........SIP/2.0 180 Ringing Via: SIP/2.0/UDP 192.168.168.33;branch=z9hG4bKcb7d.7c08af34.2, SIP/2.0/UDP 127.0.0.1:5066;received=192.168.168.33;branch=z9hG4bK-23096-730-11 From: sipp <sip:730-23096-127.0.0.1@127.0.0.1:5066>;tag=23096SIPpTag09730 To: sut <sip:otest@testg5>;tag=17278SIPpTag01696;tag=17278SIPpTag01696 Call-ID: 730-23096-127.0.0.1 CSeq: 1 INVITE Record-Route: <sip:192.168.168.33;lr=on;ftag=23096SIPpTag09730> Contact: <sip:127.0.0.1:5063> Content-Length: 0 16:16:39.643723 IP 192.168.168.33.5060 > 192.168.168.33.5066: SIP, length: 416 E.....@.@.g....!...!.......MSIP/2.0 180 Ringing Via: SIP/2.0/UDP 127.0.0.1:5066;received=192.168.168.33;branch=z9hG4bK-23096-730-11 From: sipp <sip:730-23096-127.0.0.1@127.0.0.1:5066>;tag=23096SIPpTag09730 To: sut <sip:otest@testg5>;tag=17278SIPpTag01696;tag=17278SIPpTag01696 Call-ID: 730-23096-127.0.0.1 CSeq: 1 INVITE Record-Route: <sip:192.168.168.33;lr=on;ftag=23096SIPpTag09730> Contact: <sip:127.0.0.1:5063> Content-Length: 0 16:16:39.797641 IP 192.168.168.33.5066 > 192.168.168.33.5060: SIP, length: 434 E.....@.@.g....!...!......._BYE sip:127.0.0.1:5063 SIP/2.0 Via: SIP/2.0/UDP 127.0.0.1:5066;branch=z9hG4bK-23096-730-46 From: sipp <sip:730-23096-127.0.0.1@127.0.0.1:5066>;tag=23096SIPpTag09730 To: sut <sip:service@192.168.168.33:5060>;tag=17278SIPpTag01696 Route: <sip:192.168.168.33;lr=on;ftag=23096SIPpTag09730> Call-ID: 730-23096-127.0.0.1 CSeq: 2 BYE Contact: sip:sipp@127.0.0.1:5066 Max-Forwards: 70 Subject: Performance Test Content-Length: 0 16:16:39.798436 IP 192.168.168.33.5060 > 127.0.0.1.5063: SIP, length: 528 E..,..@.@.P....!............BYE sip:127.0.0.1:5063 SIP/2.0 Record-Route: <sip:192.168.168.33;lr=on;ftag=23096SIPpTag09730> Via: SIP/2.0/UDP 192.168.168.33;branch=z9hG4bK9b7d.0423bf25.0 Via: SIP/2.0/UDP 127.0.0.1:5066;received=192.168.168.33;branch=z9hG4bK-23096-730-46 From: sipp <sip:730-23096-127.0.0.1@127.0.0.1:5066>;tag=23096SIPpTag09730 To: sut <sip:service@192.168.168.33:5060>;tag=17278SIPpTag01696 Call-ID: 730-23096-127.0.0.1 CSeq: 2 BYE Contact: sip:sipp@127.0.0.1:5066 Max-Forwards: 69 Subject: Performance Test Content-Length: 0 16:16:39.798535 IP 192.168.168.33.5063 > 192.168.168.33.5060: SIP, length: 394 E.....@.@.g....!...!.......7SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.168.33;branch=z9hG4bK9b7d.0423bf25.0, SIP/2.0/UDP 127.0.0.1:5066;received=192.168.168.33;branch=z9hG4bK-23096-730-46 From: sipp <sip:730-23096-127.0.0.1@127.0.0.1:5066>;tag=23096SIPpTag09730 To: sut <sip:service@192.168.168.33:5060>;tag=17278SIPpTag01696 Call-ID: 730-23096-127.0.0.1 CSeq: 2 BYE Contact: <sip:127.0.0.1:5063> Content-Length: 0 16:16:39.798814 IP 192.168.168.33.5060 > 192.168.168.33.5066: SIP, length: 336 E..l..@.@.g....!...!.....X..SIP/2.0 200 OK Via: SIP/2.0/UDP 127.0.0.1:5066;received=192.168.168.33;branch=z9hG4bK-23096-730-46 From: sipp <sip:730-23096-127.0.0.1@127.0.0.1:5066>;tag=23096SIPpTag09730 To: sut <sip:service@192.168.168.33:5060>;tag=17278SIPpTag01696 Call-ID: 730-23096-127.0.0.1 CSeq: 2 BYE Contact: <sip:127.0.0.1:5063> Content-Length: 0 16:16:40.257973 IP 192.168.168.33.5060 > 127.0.0.1.5063: SIP, length: 528 E..,..@.@.P....!............BYE sip:127.0.0.1:5063 SIP/2.0 Record-Route: <sip:192.168.168.33;lr=on;ftag=23096SIPpTag09730> Via: SIP/2.0/UDP 192.168.168.33;branch=z9hG4bK9b7d.0423bf25.0 Via: SIP/2.0/UDP 127.0.0.1:5066;received=192.168.168.33;branch=z9hG4bK-23096-730-46 From: sipp <sip:730-23096-127.0.0.1@127.0.0.1:5066>;tag=23096SIPpTag09730 To: sut <sip:service@192.168.168.33:5060>;tag=17278SIPpTag01696 Call-ID: 730-23096-127.0.0.1 CSeq: 2 BYE Contact: sip:sipp@127.0.0.1:5066 Max-Forwards: 69 Subject: Performance Test Content-Length: 0 16:16:40.258080 IP 192.168.168.33.5063 > 192.168.168.33.5060: SIP, length: 394 E.....@.@.g....!...!.......7SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.168.33;branch=z9hG4bK9b7d.0423bf25.0, SIP/2.0/UDP 127.0.0.1:5066;received=192.168.168.33;branch=z9hG4bK-23096-730-46 From: sipp <sip:730-23096-127.0.0.1@127.0.0.1:5066>;tag=23096SIPpTag09730 To: sut <sip:service@192.168.168.33:5060>;tag=17278SIPpTag01696 Call-ID: 730-23096-127.0.0.1 CSeq: 2 BYE Contact: <sip:127.0.0.1:5063> Content-Length: 0 16:16:41.285493 IP 192.168.168.33.5060 > 127.0.0.1.5063: SIP, length: 528 E..,..@.@.P....!............BYE sip:127.0.0.1:5063 SIP/2.0 Record-Route: <sip:192.168.168.33;lr=on;ftag=23096SIPpTag09730> Via: SIP/2.0/UDP 192.168.168.33;branch=z9hG4bK9b7d.0423bf25.0 Via: SIP/2.0/UDP 127.0.0.1:5066;received=192.168.168.33;branch=z9hG4bK-23096-730-46 From: sipp <sip:730-23096-127.0.0.1@127.0.0.1:5066>;tag=23096SIPpTag09730 To: sut <sip:service@192.168.168.33:5060>;tag=17278SIPpTag01696 Call-ID: 730-23096-127.0.0.1 CSeq: 2 BYE Contact: sip:sipp@127.0.0.1:5066 Max-Forwards: 69 Subject: Performance Test Content-Length: 0 16:16:41.285593 IP 192.168.168.33.5063 > 192.168.168.33.5060: SIP, length: 394 E.....@.@.g....!...!.......7SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.168.33;branch=z9hG4bK9b7d.0423bf25.0, SIP/2.0/UDP 127.0.0.1:5066;received=192.168.168.33;branch=z9hG4bK-23096-730-46 From: sipp <sip:730-23096-127.0.0.1@127.0.0.1:5066>;tag=23096SIPpTag09730 To: sut <sip:service@192.168.168.33:5060>;tag=17278SIPpTag01696 Call-ID: 730-23096-127.0.0.1 CSeq: 2 BYE Contact: <sip:127.0.0.1:5063> Content-Length: 0 16:16:41.695686 IP 192.168.168.33.5060 > 192.168.168.33.5063: SIP, length: 731 E.....@.@.fZ...!...!........INVITE sip:otest@testg5 SIP/2.0 Record-Route: <sip:192.168.168.33;lr=on;ftag=23096SIPpTag09730> Via: SIP/2.0/UDP 192.168.168.33;branch=z9hG4bKcb7d.7c08af34.0 Via: SIP/2.0/UDP 127.0.0.1:5066;received=192.168.168.33;branch=z9hG4bK-23096-730-1 From: sipp <sip:730-23096-127.0.0.1@127.0.0.1:5066>;tag=23096SIPpTag09730 To: sut <sip:otest@testg5> Call-ID: 730-23096-127.0.0.1 CSeq: 1 INVITE Contact: sip:sipp@127.0.0.1:5066 Max-Forwards: 69 Expires: 180 Subject: Performance Test Content-Type: application/sdp Content-Length: 188 v=0 o=user1 53655765 2353687637 IN IP4 127.0.0.1 s=- c=IN IP4 127.0.0.1 t=0 0 m=audio 8925 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-11,16 16:16:43.338592 IP 192.168.168.33.5060 > 127.0.0.1.5063: SIP, length: 528 E..,..@.@.P....!............BYE sip:127.0.0.1:5063 SIP/2.0 Record-Route: <sip:192.168.168.33;lr=on;ftag=23096SIPpTag09730> Via: SIP/2.0/UDP 192.168.168.33;branch=z9hG4bK9b7d.0423bf25.0 Via: SIP/2.0/UDP 127.0.0.1:5066;received=192.168.168.33;branch=z9hG4bK-23096-730-46 From: sipp <sip:730-23096-127.0.0.1@127.0.0.1:5066>;tag=23096SIPpTag09730 To: sut <sip:service@192.168.168.33:5060>;tag=17278SIPpTag01696 Call-ID: 730-23096-127.0.0.1 CSeq: 2 BYE Contact: sip:sipp@127.0.0.1:5066 Max-Forwards: 69 Subject: Performance Test Content-Length: 0 16:16:43.338785 IP 192.168.168.33.5063 > 192.168.168.33.5060: SIP, length: 408 E.....@.@.g....!...!.......ESIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.168.33;branch=z9hG4bK9b7d.0423bf25.0, SIP/2.0/UDP 127.0.0.1:5066;received=192.168.168.33;branch=z9hG4bK-23096-730-46 From: sipp <sip:730-23096-127.0.0.1@127.0.0.1:5066>;tag=23096SIPpTag09730 To: sut <sip:service@192.168.168.33:5060>;tag=17278SIPpTag01696 Call-ID: 730-23096-127.0.0.1 CSeq: 2 BYE Contact: <sip:127.0.0.1:5063;transport=UDP> Content-Length: 0

5 47

[Kamailio-Users] Help!! Delay in Invite with Authentication
by Krunal Patel 20 Dec '08

20 Dec '08

Hi, I am using openser 1.2.3. >From a router calls comes to openser. Router is PATTON 4960. I am using domain name to send calls to openser. First invite comes to openser & openser sends 407 to the router & then getting ACK from the router to openser. Now the invite with authentication comes after almost 10 to 11 sec Since ACK comes to openser. Here is the trace: # U 2008/12/19 12:24:24.374228 XXX.XXX.XXX.XXX:5060 -> YYY.YYY.YYY.YYY:5060 INVITE sip:[TO_NUMBER]@[EMAIL PROTECTED] SIP/2.0. Via: SIP/2.0/UDP XXX.XXX.XXX.XXX:5060;branch=z9hG4bK227032cab. Max-Forwards: 70. Content-Length: 341. To: sip:[TO_NUMBER]@[EMAIL PROTECTED]. From: sip:[FROM_NUMBER]@[EMAIL PROTECTED];tag=72a0c76ae3d477c. ... # U 2008/12/19 12:24:24.374544 YYY.YYY.YYY.YYY:5060 -> XXX.XXX.XXX.XXX:5060 SIP/2.0 407 Proxy Authentication Required. Via: SIP/2.0/UDP XXX.XXX.XXX.XXX:5060;branch=z9hG4bK227032cab;rport=5060. To: sip:[TO_NUMBER]@[EMAIL PROTECTED];tag=b802e73ab92fec121a4f880263d541a3.7575. From: sip:[FROM_NUMBER]@[EMAIL PROTECTED];tag=72a0c76ae3d477c. ... # U 2008/12/19 12:24:24.407646 XXX.XXX.XXX.XXX:5060 -> YYY.YYY.YYY.YYY:5060 ACK sip:[TO_NUMBER]@[EMAIL PROTECTED] SIP/2.0. Via: SIP/2.0/UDP XXX.XXX.XXX.XXX:5060;branch=z9hG4bK227032cab. Max-Forwards: 70. Content-Length: 0. To: sip:[TO_NUMBER]@[EMAIL PROTECTED];tag=b802e73ab92fec121a4f880263d541a3.7575. Route: <sip:[EMAIL PROTECTED]:5060;lr>. .... # U 2008/12/19 12:24:35.667448 XXX.XXX.XXX.XXX:5060 -> YYY.YYY.YYY.YYY:5060 INVITE sip:[TO_NUMBER]@[EMAIL PROTECTED] SIP/2.0. Via: SIP/2.0/UDP XXX.XXX.XXX.XXX:5060;branch=z9hG4bK3362d177f. Max-Forwards: 70. Content-Length: 341. To: sip:[TO_NUMBER]@[EMAIL PROTECTED]. From: sip:[FROM_NUMBER]@[EMAIL PROTECTED];tag=72a0c76ae3d477c. Route: <sip:[EMAIL PROTECTED]:5060;lr>. ... U 2008/12/19 12:24:35.692576 YYY.YYY.YYY.YYY:5060 -> ZZZ.ZZZ.ZZZ.ZZZ:5060 INVITE sip:[TO_NUMBER]@ZZZ.ZZZ.ZZZ.ZZZ:5060;transport=udp SIP/2.0. Record-Route: <sip:[TO_NUMBER]@[EMAIL PROTECTED]:5060;ftag=72a0c76ae3d477c;lr=on>. Via: SIP/2.0/UDP YYY.YYY.YYY.YYY;branch=z9hG4bK32dd.6cc062c5.0. Via: SIP/2.0/UDP XXX.XXX.XXX.XXX:5060;rport=5060;branch=z9hG4bK3362d177f. Max-Forwards: 69. Content-Length: 341. To: sip:[TO_NUMBER]@[EMAIL PROTECTED]. From: sip:[FROM_NUMBER]@[EMAIL PROTECTED];tag=72a0c76ae3d477c. ... U 2008/12/19 12:24:35.731432 ZZZ.ZZZ.ZZZ.ZZZ:5060 -> YYY.YYY.YYY.YYY:5060 SIP/2.0 100 Trying. Call-ID: 1c00f084ccd0232ad5ab638dc6a7ccfd@[EMAIL PROTECTED]. CSeq: 1965370819 INVITE. From: sip:[FROM_NUMBER]@[EMAIL PROTECTED];tag=72a0c76ae3d477c. .... U 2008/12/19 12:24:35.849714 ZZZ.ZZZ.ZZZ.ZZZ:5060 -> YYY.YYY.YYY.YYY:5060 SIP/2.0 183 Session Progress. Call-ID: 1c00f084ccd0232ad5ab638dc6a7ccfd@[EMAIL PROTECTED]. CSeq: 1965370819 INVITE. From: sip:[FROM_NUMBER]@[EMAIL PROTECTED];tag=72a0c76ae3d477c. To: sip:[TO_NUMBER]@[EMAIL PROTECTED];tag=86f125f633683d0. ... # U 2008/12/19 12:24:35.849961 YYY.YYY.YYY.YYY:5060 -> XXX.XXX.XXX.XXX:5060 SIP/2.0 183 Session Progress. Call-ID: 1c00f084ccd0232ad5ab638dc6a7ccfd@[EMAIL PROTECTED]. CSeq: 1965370819 INVITE. From: sip:[FROM_NUMBER]@[EMAIL PROTECTED];tag=72a0c76ae3d477c. To: sip:[TO_NUMBER]@[EMAIL PROTECTED];tag=86f125f633683d0. Can anybody help me to trobleshoot the issue? Thanks in Advance!! -- Krunal patel

2 1

[Serusers] Gentilini, Paul is out of the office.
by PGentilini＠intellicare.com 19 Dec '08

19 Dec '08

I will be out of the office starting 12/18/2008 and will not return until 12/29/2008. Please contact the CSC at 888-899-4227 if you need immediate assistance.

1 0

Re: [Kamailio-Users] Kamailio in Red Hat 4 with mysql and carrierroute
by Juan Asencio 19 Dec '08

19 Dec '08

> On Monday 08 December 2008, Juan Asencio wrote: >> Thank you for your fast response. So after I compile them, the files >> carrierroute.so should appear on the directory of modules? >> >> Because I thought did it right, but I can't see the carrierroute.so >> anywhere. So I'm not sure if I did it right :( > > Hi Juan, > > you need to edit the exclude_modules parameter in the Makefile, and remove > the > db_mysql and carrierroute module. After a new make; make install this > modules > should also be available. > > Cheers, > > Henning > Hi Henning, now the modules are available on the kamailio.cfg file, but when I run the command "kamctl start" I got the following error: ERROR: PID file /var/run/kamailio.pid does not exist -- Kamailio start failed But, if comment on the .cfg file the carrierroute.so line, Kamailio is able to start. Do you have any suggestions about what I'm doing wrong? Cheers, Juan.-

2 2

[Serusers] database query
by Netadmin 19 Dec '08

19 Dec '08

Hello, Is there a function i can use to check if a user exist in subscriber table? Something similar to lookup? thanks

2 1

[Serusers] sip register problem SER behind NAT
by WANG Zhenzhong 19 Dec '08

19 Dec '08

I set the SER behind a NAT. The SER’s private IP is 192.168.9.88 The NAT’s public IP is 122.194.106.139 I use the eyebeam to register to SER from internet via the NAT address. But when the SER receive the register message, it find the IP(122.194.106.139) in “To” & “from” line is different from the local IP(192.168.9.88), So the SER forward the register message and the register is failed. How solve this problem. Thanks. 王振中 wangzz 艾诺通信系统（苏州）有限责任公司苏州工业园区国际科技园一期203A wangzz(a)avonaco.com ============================================

2 4

[Serusers] the language of ser.cfg
by WANG Zhenzhong 19 Dec '08

19 Dec '08

I want to change the ser.cfg. Such as I want to define a new variable, and assign a string, etc But I don’t know which language the ser.cfg use. Is there any document to introduce the expression and language of ser.cfg? THANKS 王振中 wangzz 艾诺通信系统（苏州）有限责任公司苏州工业园区国际科技园一期203A wangzz(a)avonaco.com ============================================

1 0

[Kamailio-Users] Is there a way to detect use_media_proxy called or not?
by Krunal Patel 18 Dec '08

18 Dec '08

Hi, Does anybody know how to detect whether use_media_proxy is called? What I want to do is: Do end_media_session for bye or cancel if & only if use_media_proxy has been called during invite or reply route. Is it possible? If it is then please let me know how to implement it? Thanks in advance -- Krunal Patel

4 4

[Serusers] SER with FreeRADIUS
by Robert Borz 18 Dec '08

18 Dec '08

Hi guys, we're using ser 0.9.7 on Debian/Lenny together with FreeRADIUS. Authentication against the RADIUS already works basically for our sip clients. Now we want to make the contact information persisting restarts of SER. Is there a way to store the contact information for the registered sip clients in the radius database or must an additional database, e.g. mysql or postgres, used for that? Regards, Robert ____________________________________________________________________ Psssst! Schon vom neuen WEB.DE MultiMessenger gehört? Der kann`s mit allen: http://www.produkte.web.de/messenger/?did=3123

1 0

Re: [Kamailio-Users] openser and asterisk auth problem.
by BERGANZ François 18 Dec '08

18 Dec '08

I want to authenticate in openser some users which are in asterisk conf (to do load balancing with another asterisk). If I delete the user from the asterisk config and insecure=invite for the openser, asterisk accept the call, but, I want that asterisk see that it is that user which is doing the call. Cordialement, BERGANZ François http://www.acropolistelecom.net  Pensez à l'Environnement, n'imprimez ce mail que si nécessaire. -----Message d'origine----- De : Andrew V.Statsenko [mailto:alter@siptalk.ru] Envoyé : jeudi 18 décembre 2008 11:00 À : BERGANZ François Objet : ***SPAM*** Re: [Kamailio-Users] openser and asterisk auth problem. В Чтв, 18/12/2008 в 10:31 +0100, BERGANZ François пишет: > -----I have that error: > <--- SIP read from UDP://192.168.1.156:5060 ---> > INVITE sip:33662971130@192.168.1.156 SIP/2.0 > Record-Route: <sip:192.168.1.156;lr=on;ftag=0c46027a> > Via: SIP/2.0/UDP 192.168.1.156;branch=z9hG4bK20d2.de427962.0 > Via: SIP/2.0/UDP 192.168.1.60:43490;branch=z9hG4bK-d8754z-c15d2350d0742a11-1---d8754z-;rport=43490 > Max-Forwards: 70 > Contact: <sip:6833211245@192.168.1.60:43490> > To: "33662971130"<sip:33662971130@192.168.1.156> > From: "6833211245"<sip:6833211245@192.168.1.156>;tag=0c46027a > Call-ID: YTkxOWU5MGJjZjJhMWFmODZhMzZkMTU1YzUzYjUyMTc. > CSeq: 2 INVITE > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO > Content-Type: application/sdp > User-Agent: X-Lite release 1100l stamp 47546 > Content-Length: 231 [..] > <-------------> > --- (14 headers 10 lines) --- > Sending to 192.168.1.156 : 5060 (no NAT) > Using INVITE request as basis request - YTkxOWU5MGJjZjJhMWFmODZhMzZkMTU1YzUzYjUyMTc. > Found user '6833211245' for '6833211245' This is the key trouble in your configuration: Asterisk trying to authenticate this call as call from _user_ (INVITE->401->INVITE+auth), but not as _peer_. Will you describe us where you want to authenticate you users : - at the OpenSER frontend (BTW, I don't see auth headers in first INVITE) - or in the Asterisk backend ? Which service logic you are building ? -- WBR, Alter

3 4

Re: [Kamailio-Users] serMyAdmin database connection
by Flavio Goncalves 18 Dec '08

18 Dec '08

Message: 1 Date: Wed, 17 Dec 2008 16:29:56 +0200 From: TCB <tawandac(a)gmail.com> Subject: [Kamailio-Users] serMyAdmin error To: users <users(a)lists.kamailio.net> Message-ID: <f9db9e000812170629v34e6e1edr2a472912427c78eb(a)mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" I'm trying to install serMyAdmin using a remote mysql DB. I keep getting the following error. Caused by: org.springframework.jdbc.CannotGetJdbcConnectionException: Could not get JDBC Connection; nested exception is com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure I changed context.xml to point to the remote DB. Where else should i change DB the credential -- TC Please try to connect to your database using mysql command line, to check if your permissions are ok. I will verify the JDBC connection with a remote database. Regards, Flavio E. Goncalves

1 0

[Kamailio-Users] openser and asterisk auth problem.
by BERGANZ François 18 Dec '08

18 Dec '08

Hello, I have : ASTERISK-----OPENSER-----SOFTPHONE My softphone auth to openser (with username/password of asterisk sync with a database) Openser forward the INVITE to asterisk and asterisk return Unautorize! I tried to have the same realm to try de have the same auth for asterisk and openser But without success. In fact, I need to auth to openser(with asterisk config user in the database) and forward to asterisk the INVITE. Thank you Cordialement, BERGANZ François P Pensez à l'Environnement, n'imprimez ce mail que si nécessaire.

2 2

[Kamailio-Users] Use Carrierroute to rewrite from_uri based on prefix table
by rod 18 Dec '08

18 Dec '08

Hi all, I've been able to rewrite R_URI based on prefix matching in the carrierroute module, using: cr_route("default", "0", "$rU", "$rU", "call_id") I used this to normalize the ruri to E164: ex: in france, the country code is +33, if someone dials "01 10 10 10 10", I strip the first 0 and prefix with 33 so that I get 331 10 10 10 10 (space are there for convenience :p) What I'd like to do is to use the carrierroute module to do the same but for from uri: ex: I receive a call on my phone with a caller using e164 (from_uri: 331 20 20 20 20) and I'd like to present this number as 01 20 20 20 20 to the callee. I added a prefix 331 in the carrierroute tables. I tried this: - cr_route("default", "0", "$fU", "$fU", "call_id") - cr_route("default", "0", "$fU", "$fU", "from_uri") - cr_route("default", "0", "$fU", "$rU", "call_id") - cr_route("default", "0", "$fU", "$rU", "from_uri") but I've been unsuccessful with this. Is there a way to achieve from_uri translation using the carrierroute module. Regards, rod

2 2

[Kamailio-Users] nat problems
by Ricky Gutierrez 17 Dec '08

17 Dec '08

Hi list, I want to comment some problems of nat that I have, I have two connected remote UAC in a same location UAC 202 REMOTE A UAC 123 REMOTE A if the UAC 123 calls to UAC 202 there is not bidirectional audio UAC 204 REMOTE B UAC 122 REMOTE C if the UAC 122 calls to UAC 202 if there is bidirectional audio some help like I can solve this problem?, the remote clients in site A they are behind a nat symetrics I am using rtpproxy version 1.1 and openser 1.3.2 log sip U +2.975758 190.212.49.86:58944 -> 190.184.22.152:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 190.184.22.152:5060;branch=z9hG4bK74f3.13c6ec23.0 Via: SIP/2.0/UDP 192.168.10.37:5060;rport=63451;received=190.212.49.86;branch=z9hG4bK33571797d7d31cb0 Record-Route: <sip:190.184.22.152;lr=on;ftag=0966ab4346392f45> From: "ricardo-elim" <sip:123@190.184.22.152>;tag=0966ab4346392f45 To: <sip:202@190.184.22.152>;tag=15c74eb7e1a2ae92 Call-ID: 4dfa1b96e314c165(a)192.168.10.37 CSeq: 17345 INVITE User-Agent: Grandstream GXP2020 1.1.6.16 Contact: <sip:202@192.168.10.40:5064;transport=udp> Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE Content-Type: application/sdp Supported: replaces, timer Content-Length: 214 v=0 o=202 8000 8000 IN IP4 192.168.10.40 s=SIP Call c=IN IP4 192.168.10.40 t=0 0 m=audio 5004 RTP/AVP 18 101 a=sendrecv a=rtpmap:18 G729/8000 a=ptime:20 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-11 # U +0.000475 190.184.22.152:5060 -> 190.212.49.86:63451 SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.10.37:5060;rport=63451;received=190.212.49.86;branch=z9hG4bK33571797d7d31cb0 Record-Route: <sip:190.184.22.152;lr=on;ftag=0966ab4346392f45> From: "ricardo-elim" <sip:123@190.184.22.152>;tag=0966ab4346392f45 To: <sip:202@190.184.22.152>;tag=15c74eb7e1a2ae92 Call-ID: 4dfa1b96e314c165(a)192.168.10.37 CSeq: 17345 INVITE User-Agent: Grandstream GXP2020 1.1.6.16 Contact: <sip:202@190.212.49.86:58944;transport=udp;nat=yes> Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE Content-Type: application/sdp Supported: replaces, timer Content-Length: 234 P-hint: onreply_route|force_rtp_proxy P-hint: Onreply-route - fixcontact v=0 o=202 8000 8000 IN IP4 192.168.10.40 s=SIP Call c=IN IP4 190.184.22.152 t=0 0 m=audio 35036 RTP/AVP 18 101 a=sendrecv a=rtpmap:18 G729/8000 a=ptime:20 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-11 a=nortpproxy:yes # U +0.241543 190.212.49.86:63451 -> 190.184.22.152:5060 ACK sip:202@190.212.49.86:58944;transport=udp;nat=yes SIP/2.0 Via: SIP/2.0/UDP 192.168.10.37:5060;branch=z9hG4bKa26522558c582a68 Route: <sip:190.184.22.152;lr=on;ftag=0966ab4346392f45> From: "ricardo-elim" <sip:123@190.184.22.152>;tag=0966ab4346392f45 To: <sip:202@190.184.22.152>;tag=15c74eb7e1a2ae92 Contact: <sip:123@192.168.10.37:5060;transport=udp> Supported: path Proxy-Authorization: Digest username="123", realm="190.184.22.152", algorithm=MD5, uri="sip:202@190.184.22.152", nonce="49485f8958ba6dc4e39ee5893d15ea3e60ae19ad", response="afb5db07f3a90d4cfc6ea483fd120404" Call-ID: 4dfa1b96e314c165(a)192.168.10.37 CSeq: 17345 ACK User-Agent: Grandstream BT200 1.1.6.16 Max-Forwards: 70 Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK Content-Length: 0 # U +0.000334 190.184.22.152:5060 -> 190.212.49.86:58944 ACK sip:202@190.212.49.86:58944;transport=udp SIP/2.0 Record-Route: <sip:190.184.22.152;lr=on;ftag=0966ab4346392f45> Via: SIP/2.0/UDP 190.184.22.152;branch=z9hG4bK74f3.13c6ec23.2 Via: SIP/2.0/UDP 192.168.10.37:5060;rport=63451;received=190.212.49.86;branch=z9hG4bKa26522558c582a68 From: "ricardo-elim" <sip:123@190.184.22.152>;tag=0966ab4346392f45 To: <sip:202@190.184.22.152>;tag=15c74eb7e1a2ae92 Contact: <sip:123@190.212.49.86:63451;transport=udp;nat=yes> Supported: path Proxy-Authorization: Digest username="123", realm="190.184.22.152", algorithm=MD5, uri="sip:202@190.184.22.152", nonce="49485f8958ba6dc4e39ee5893d15ea3e60ae19ad", response="afb5db07f3a90d4cfc6ea483fd120404" Call-ID: 4dfa1b96e314c165(a)192.168.10.37 CSeq: 17345 ACK User-Agent: Grandstream BT200 1.1.6.16 Max-Forwards: 69 Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK Content-Length: 0 # U +0.383479 190.184.22.152:5060 -> 190.212.49.86:58944 OPTIONS sip:190.212.49.86:58944 SIP/2.0 Via: SIP/2.0/UDP 190.184.22.152:5060;branch=0 From: sip:pinger@190.184.22.152;tag=d7259e51 To: sip:190.212.49.86:58944 Call-ID: 1f9f65c1-fcccdef2-674a(a)190.184.22.152 CSeq: 1 OPTIONS Content-Length: 0 # U +0.173847 190.212.49.86:58944 -> 190.184.22.152:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 190.184.22.152:5060;branch=0 From: sip:pinger@190.184.22.152;tag=d7259e51 To: sip:190.212.49.86:58944;tag=15c74eb7e1a2ae92 Call-ID: 1f9f65c1-fcccdef2-674a(a)190.184.22.152 CSeq: 1 OPTIONS User-Agent: Grandstream GXP2020 1.1.6.16 Contact: <sip:202@192.168.10.40:5064;transport=udp> Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE Supported: replaces, timer Content-Length: 0 # U +0.826048 190.184.22.152:5060 -> 190.212.35.160:50273 OPTIONS sip:190.212.35.160:50273 SIP/2.0 Via: SIP/2.0/UDP 190.184.22.152:5060;branch=0 From: sip:pinger@190.184.22.152;tag=e7259e51 To: sip:190.212.35.160:50273 Call-ID: 1f9f65c1-0dccdef2-774a(a)190.184.22.152 CSeq: 1 OPTIONS Content-Length: 0 # U +0.192726 190.212.35.160:50273 -> 190.184.22.152:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 190.184.22.152:5060;branch=0 From: sip:pinger@190.184.22.152;tag=e7259e51 To: sip:190.212.35.160:50273;tag=c2c330e1c7bae7ba Call-ID: 1f9f65c1-0dccdef2-774a(a)190.184.22.152 CSeq: 1 OPTIONS User-Agent: Grandstream GXP2000 1.1.6.16 Contact: <sip:203@192.168.0.16:5060;transport=udp;user=phone> Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE Supported: replaces, timer Content-Length: 0 # U +1.807039 192.168.11.1:5060 -> 192.168.11.30:5060 OPTIONS sip:192.168.11.30:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.11.1:5060;branch=0 From: sip:pinger@190.184.22.152;tag=f7259e51 To: sip:192.168.11.30:5060 Call-ID: 1f9f65c1-1dccdef2-974a(a)192.168.11.1 CSeq: 1 OPTIONS Content-Length: 0 regards rickygm

2 1

[Kamailio-Users] simple call between 2phones
by BERGANZ François 17 Dec '08

17 Dec '08

Hello, I know kamailio, but, I dont know how to do : Call between 2phone which are registered ! Know you how to do ? Cordialement, BERGANZ François P Pensez à l'Environnement, n'imprimez ce mail que si nécessaire.

2 1

[Kamailio-Users] serMyAdmin error
by TCB 17 Dec '08

17 Dec '08

I'm trying to install serMyAdmin using a remote mysql DB. I keep getting the following error. Caused by: org.springframework.jdbc.CannotGetJdbcConnectionException: Could not get JDBC Connection; nested exception is com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure I changed context.xml to point to the remote DB. Where else should i change DB the credential -- TC -- TC

1 0

[Kamailio-Users] failed to request mysql lock ()
by Brian Del Shasta 16 Dec '08

16 Dec '08

Is this an issue? Dec 16 14:47:45 fndipt03 cdrtool[10738]: Database error: failed to request mysql lock () Dec 16 14:47:45 fndipt03 cdrtool[10738]: Unlock ser_radius:radacct Dec 16 14:47:45 fndipt03 cdrtool[10738]: Error in unLockNormalization() The only problem I have is I am unable to get the pricing to work, but I think that may be unrelated... Thanks

1 0

[Kamailio-Users] Kamailio v1.4.3 Released
by Daniel-Constantin Mierla 16 Dec '08

16 Dec '08

Hello, a new release in 1.4 series is out. Kamailio 1.4.3 is based on the latest version of branch 1.4, including many fixes in code and documentation, therefore those running 1.4.0, 1.4.1 or 1.4.2 are advised to upgrade. Source tarballs are available at: http://www.kamailio.org/pub/kamailio/1.4.3/src/ Detailed changelog: http://www.kamailio.org/pub/kamailio/1.4.3/ChangeLog Download via SVN: svn co https://openser.svn.sourceforge.net/svnroot/openser/branches/1.4 kamailio Sources for this release can be browsed at: http://openser.svn.sourceforge.net/viewvc/openser/branches/1.4/ Project site at SourceForge.net (still using old name): http://sourceforge.net/projects/openser/ Modules' documentation: http://www.kamailio.org/docs/modules/1.4.x/ What is new in 1.4.x release series is summarized in the announcement of v1.4.0: http://www.kamailio.org/mos/view/KAMAILIO-v1.4.0-Released Note: Kamailio is the new name of OpenSER project. First version under Kamailio name was 1.4.0. Older versions will continue to use OpenSER name. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

1 0

[Kamailio-Users] memory leak debugging
by joy yue 16 Dec '08

16 Dec '08

Hi, I was trying to debugg if I hit a memory leak issue. I delete "-DF_MALLOC" line and insert a "-DDBG_QM_MALLOC" line of DEFS string in Makefile.def. I was able to compile openser with new Makefile.def. But when running openser, I get error, fm_free() is not defined, in many modules. And there is a flag mismatch between openser core and modules compilation. Core compilation has DDBG_QM_MALLOC flag, but module compilation still uses F_MALLOC instead of DDBG_QM_MALLOC. Is there anything else I need to change in Makefile.defs? Thanks, -Joy

4 8

Re: [Kamailio-Users] Kamailio in Red Hat 4 with mysql and carrierroute
by Henning Westerholt 16 Dec '08

16 Dec '08

On Tuesday 16 December 2008, Juan Asencio wrote: > [..] > I need to test the carrierroute module in Kamailio and I been reading the > documentation about it. > > http://www.kamailio.org/docs/modules/devel/carrierroute.html#id2506610 > > But this something entirely new for me. So I have a couple of questions > that I hope you can answer or guide me to where I could found an answer. > > I need to test it with two Asterisk gateways. So I guess I need to edit my > kamailio.cfg file as the example on "Example 1.19. Configuration example - > module configuration" My question is: On prefix 49 and prefix NULL, are > these the two routes available? If the prefix is 49, so the call go > through proxy1.localdomain or proxy2.localdomain and if the prefix is NULL > it would go through register1.localdomain or register2.localdomain? > > It is proxy and register the gateways? Hi Juan, please write this questions to the user list. The config in question is probably: domain proxy { prefix 49 { ... } } domain register { prefix NULL { ... } } This defines two "domains" in the default carrier tree. The 'proxy' domain will be used if you specify 'proxy' in the cr_route calls, the same applies to the 'register' case. So if you want to distribute traffic between two asterisk, just use one domain, and a empty (NULL) prefix. See the following example config: domain foobar { prefix 49 { max_targets = 2 target box1.localdomain { prob = 0.500000 hash_index = 1 status = 1 comment = "test target 1" } target box2.localdomain { prob = 0.500000 hash_index = 2 status = 1 comment = "test target 2" } } prefix NULL { max_targets = 1 target box3.localdomain { prob = 1.000000 hash_index = 1 status = 1 comment = "test target 3" } } } This way all traffic with the prefix '49' will be equally distributed between box1 and box2, and all other prefixes will be routed to box3. Hope this is now more clear. > Could you suggest me what to read in order to get a better understanding > of this module? You probably need to experiment a bit. If you increase the log level to INFO, then the module will report what it does, increase to DEBUG to get even more informations, e.g. about domain searching. Take a look to the mailing list archives, if you get stuck just ask at the user list. Cheers, Henning

1 0

[Kamailio-Users] k/o xlog and pv modules for srouter
by Daniel-Constantin Mierla 16 Dec '08

16 Dec '08

Hello, I have uploaded xlog and (stripped) pv Kamailio/Openser modules to sip-router.org site at: http://sip-router.org/pub/tmp/miconda/ If you are willing to test them, then just get the branch "master" from git and merge with "daniel/pv". Details about GIT repository: http://sip-router.org/2008/11/18/git-repository-online/ The pv module does not include yet the pseudo-variables and transformations dependent of K/O extensions (e.g., branch, script flags, ...). Probably one important to decide upon is the AVP (to start a new discussion about it separately). The ones missing now will be gradually activated as dependent code is sorted out. Testing and feedback is welcome. Andrei is doing heavy work to improve the config script interpreter for string and arithmetic operations, you can track the commits at: http://lists.sip-router.org/pipermail/sr-dev/ Once work is finished and the developers' branches are merged, we can mark an important milestone - K/O pseudo-variables working in sip-router config file, opening full functionality for large set of K/O modules and clean compatibility of config files for many typical deployments. SIP-Router is able to load now both types of modules: ser and k/o. DB APIs from both projects were tested as library, from K/O point of view mi and statistics API are the extensions yet to be made libraries for sip-router. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

2 2

[Kamailio-Users] CDRTool --> CDRs= signalling information ok but no Rating informations
by BERGANZ François 16 Dec '08

16 Dec '08

Hello, I could install CDRTool. I have in CDRs signallings informations but dont have Rating information. Have you an idea? Id Start time Sip Proxy SIP caller In SIP destination Out Dur Price KBIn KBOut Status Codec <http://192.168.1.150/CDRTool/callsearch.phtml> 1N 2008-12-16 11:23:24 2000(a)192.168.1.155 33170725015@192.168.1.15100:19 Ok (200) Signalling information <http://192.168.1.150/CDRTool/callsearch.phtml?cdr_source=ser_radius&cdr_tab le=radacct&order_by=RadAcctId&order_type=DESC&begin_datetime=1229420460&end_ datetime=1229468100&maxrowsperpage=15&action=search&call_id=YjUwMzg1OGVlYzU4 M2QwNzNkZjQ4ZjNmYzUyZTczNGM.> Click here to show only this call id Call id: YjUwMzg1OGVlYzU4M2QwNzNkZjQ4ZjNmYzUyZTczNGM. <javascript:void(null);> Click here to see the SIP trace for this call From/to tags: 636e0825/as5d7d6d2a Start time: 2008-12-16 11:23:24 Europe/Amsterdam Stop time: 2008-12-16 11:23:43 Method: Invite from 192.168.1.60:39366 From: 2000(a)192.168.1.155 Domain: 192.168.1.155 To (dialed URI): 33170725015(a)192.168.1.155 Canonical URI: 33170725015(a)192.168.1.151 Next hop URI: 33170725015(a)192.168.1.151 Billing Party: 2000(a)192.168.1.155 Cordialement, BERGANZ François P Pensez à l'Environnement, n'imprimez ce mail que si nécessaire.

1 0

[Kamailio-Users] documenting pseudo-variables and transformations
by Daniel-Constantin Mierla 16 Dec '08

16 Dec '08

Hello, today the PV&T are documented in several places: - core PV&T were on dokuwiki page - PV exported by modules in the README As of now, all PV&T from core were moved in pv module, but they are sill documented on dokuwiki page. However, we should get to a consistent way. My suggestion is to document PV&T in docuviki, mentioning which module to load to become available. We keep a single page a reference, being easier to find all the PV&T, rather than going over all modules' README. I think user experience is more straightforward. The module readme should maintain a small section, listing the names of PV&T plus a link to dokuwiki page. Any other opinions? I am just about to document the new $T_rpl(pv) and $T_req(pv) pseudo-variables from TM, so I am waiting to do it in the proper place: http://lists.kamailio.org/pipermail/devel/2008-December/017108.html Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

2 2

[Kamailio-Users] Simple Proxying?
by Jeffrey Ollie 16 Dec '08

16 Dec '08

Hello, I'm a newbie with OpenSER/Kamailio so please bear with me. I'm trying to use OpenSER 1.3.4 and rtpproxy to connect two IP PBXs. The two PBXs (and the phones they serve) cannot talk directly to each other, they need to go through my OpenSER system. One system is a Cisco CallManager cluster (v5.1.3) which I administer and the other is a Mitel system run by another organization. I have a CentOS box running OpenSER and rtpproxy with two interfaces one on each network. Routing on the CentOS box appears correct as I can ping everything I expect to. I've gotten OpenSER configured so that SIP messages are sent between the PBXs, but the SDPs aren't getting rewritten properly and the RTP isn't getting passed through the rtpproxy. I've attached my config so far, can anyone point out where I've gone wrong or point me to some example configs that might help me out? All of the example configs that I've found so far seem to be oriented towards SIP endpoints. -- Jeff Ollie "You know, I used to think it was awful that life was so unfair. Then I thought, wouldn't it be much worse if life were fair, and all the terrible things that happen to us come because we actually deserve them? So, now I take great comfort in the general hostility and unfairness of the universe." -- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon"

2 4

[Kamailio-Users] avp script flags
by Daniel-Constantin Mierla 16 Dec '08

16 Dec '08

Hello, while adapting the PV API, I got into the AVP script flags? Is anyone still using them? If yes, for what purpose, maybe we can figure out a nicer way and drop these flags. We have to find the solution to make AVPs from kamailio/openser and ser compatible in the new sip-router.org project. Just for those not being sure what I am talking about, avp names can have flags after the name type specifier, like: $avp(i3:23) - meaning that flags 1 and 2 (bitmask ...0011) are set for that avp. As I haven't seen any related discussions for quite some time, the functionality might not be updated all over the code. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

4 6

[Kamailio-Users] tracking modules
by Daniel-Constantin Mierla 16 Dec '08

16 Dec '08

Hello, as we have a big number of modules and we did updates like renaming, merging, ..., I have created a dokuwiki page to track a module. Now it is a table that should show for each module the date (release) when it was introduced, current status and description about that. Feel free to enhance the format, the page is located at: http://www.kamailio.org/dokuwiki/doku.php/modules:status Now it is just a skeleton. I hope all of you will contribute there. You can add to description anything you believe is relevant for that module. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

1 0

[Kamailio-Users] Configuring Kamailio with Asterisk gateways
by Juan Asencio 15 Dec '08

15 Dec '08

Hi all, I'm trying to configure my kamailio sip server with two asterisk gateways. I have look for some tutorials, but the one in Kamailio website have me a little confuse, because the files content is different. I guess it must be the .cfg file from Openser the one that is describe on the website. http://kamailio.org/dokuwiki/doku.php/asterisk:realtime-integration Could any one suggest me some tutorials, to see how the kamailio.cfg file should be edited? Best regards, Juan.-

5 4

[Kamailio-Users] Contact of reply for SUBSCRIBE
by Andreas Granig 15 Dec '08

15 Dec '08

Hi all, Kamailio sends a Contact set to modparam "server_address" in the "presence" module when replying to SUBSCRIBE. Now I've seen in some clients (e.g. eyebeam) and libs (e.g. eXosip) that they send subsequent SUBSCRIBEs to this contact. In case of eXosip, it's for automatically refreshing the subscription. Problem is, that I can't tell what to put into "server_address" to handle this correctly, since just putting in the domain of my server (like "sip:my.domain") doesn't work, and putting in some generic URI like "sip:server@my.domain") doesn't make sense also, since the user doesn't exist. So, how are you supposed to handle this? Any thoughts? Andreas

2 5

[Kamailio-Users] serial forking : is hash table autoexpire working ?
by Aurelien Grimaud 15 Dec '08

15 Dec '08

Hi, I am using openser to route requests towards differents Interactive Voice Response (IVR). For this, and to manage failures, maintenance a flexible way, I use serial forking. For each requests (after loose routing process), all possible destinations are retrieved from 'location' with a modified lookup. The first one is pushed to DURI, the other ones are stored in AVP. An on_failure_route is set to get next destination if any. fr_timer is 5 secs fr_inv_timer is 120 secs. Therefore, if an IVR does not response at all within 5 secs, the serial forking mechanism is triggered. Any subsequent message *MUST* go to same IVR, this is the record_route/loose_route processing, and everything is ok for ACK or BYE. My problem is for requests that does not match loose_routing. - What about the initial INVITE being retransmitted ? - What about a CANCEL ? In those cases, the request goes to another IVR which handles it genuinely. For INVITE retransmission, the calling uac will get two different answers. If lucky, one will be canceled. For CANCEL, the message will be rejected by all destinations but the one which expects it (if lucky). To avoid this, I used dynamic avp to set nexthop for a specific callid, as soon as nexthop was chosen. These avp were stored in database and reloaded from ... This is really slowing down the system for a little annoyance ... With kamailio 1.5.0 I use new module hash table to store next hop. nexthop is cleaned on BYE, CANCEL and failures. To handle runaway calls, the autoexpire parameter of hash table is a great thing. Unfortunately It does not seem to do the job. All entries stays indefinitely in table (as shown in sht_print) Do you think these serial forking issues (re-INVITE, CANCEL) and all the work around (nexthop hash table) it need is useful ? Anyone want to share its serial forking management ? What about the autoexpire parameter for hash table ? Is it ok or did I miss something ? loadmodule "htable.so" modparam("htable", "htable", "nexthop=>size=4;autoexpire=120;") Aurelien

2 1

[Serusers] Redirect server without "305 Use Proxy"?
by Rick van Rein 14 Dec '08

14 Dec '08

Hello, I am trying to setup a redirect proxy that pre-parses SIP before it gets to the telco. It can do things like lookup speeddial-codes and map them to either a phone number or a SIP-address. My first thought was to use "305 Use Proxy" to tell phones to move on to the proxy of the telco. But 305 is discouraged on iptel.org as it is not properly standardised. 1. Am I correct in assuming that it is best to use "302 Moved Temporarily"? Using this, I would need to set the Contact: field with address(es) of new servers to appraoch. 2. What is the designated method to set Contact: in preparation of "302"? Since there may be more than one SIP-server at the provider, it is good to be able to create multiple Contact: headers. Behind the @ could be server names and ports (from SRV lookup) or IP numbers (from A lookup). 3. How to make DNS lookups for proxy servers with Ser? 4. How to fold multiple DNS lookup results onto multiple Contact: headers? I wonder if this is an existing facility in Ser, or if I should extend Ser for doing this? I hope someone on this list can help me move forward. Thanks! -Rick

1 0

[Serusers] How to make exec_dset() return false?
by John G. Rose 12 Dec '08

12 Dec '08

How do I make exec_dset() return a false? As in: if (!(exec_dset('some shell scripting stuff')) { do this....; } Thanks, John

1 0

Re: [Serusers] REGISTER control based on UA
by inge 12 Dec '08

12 Dec '08

Hi all, I'm still working on without success for the moment. I don't have an idea on the means to use AVP/DB etc. with this purpose. Someone can help me ? Regards Le lundi 24 novembre 2008 à 12:20 +0100, Atle Samuelsen a écrit : > if(search("Asterisk")){ > sl_reply("403","Go away ugly asterisk"); > break; > }else if(search("my_other_ua_i_dont_like"){ > sl_reply("403","I do not like you either"); > break; > } > > > On Mon, Nov 24, 2008 at 12:16 PM, inge <inge(a)legos.fr> wrote: > > Someone else has an idea ? I think about how to implement this kind of > > filtering with functions included in SER 0.9.6, but I still in trouble. > > > > Thanks. > > > > Le jeudi 13 novembre 2008 à 16:44 +0100, inge a écrit : > >> Hi Alexandre, > >> > >> Great workaround !! > >> > >> Maybe I can use it with Redhat if the module is compiled with x86 > >> architecture ? > >> > >> What about the "flag" field in table description ? > >> > >> Regards, > >> > >> A. LEMOINE > >> > >> Le mercredi 12 novembre 2008 à 20:59 +0300, Alexandre Snarskii a écrit : > >> > On Wed, Nov 12, 2008 at 12:59:35PM +0100, inge wrote: > >> > > Hi all, > >> > > > >> > > I look for a workaround to use a white list in addition of > >> > > authentification proces, based on User-Agent (ie. for example : deny > >> > > "Asterisk IPBX" permit "Cisco IPhone...") > >> > > >> > There is (unofficial) check_ua module added as a patch in FreeBSD port, > >> > which works exactly as 'additional UA check'. > >> > > >> > Setup is not too complicated: you must create and populate some table > >> > in your database. In my example, DB is postgresql, exact create/populate > >> > commands is the next: > >> > > >> > CREATE TABLE check_ua ( > >> > rexx VARCHAR(256) NOT NULL UNIQUE, > >> > flag INTEGER NOT NULL DEFAULT(0) > >> > ); > >> > -- main goal is to disallow user-agents with invalid symbols: > >> > INSERT INTO check_ua VALUES('^[0-9A-Za-z/.() _-]{1,64}$',1); > >> > -- in your case it should be something like > >> > INSERT INTO check_ua VALUES('^Cisco IP Phone.*',1); > >> > > >> > Then, add to global configuration: > >> > > >> > loadmodule "/usr/local/lib/ser/modules/check_ua.so" > >> > modparam("check_ua", "db_url", "postgres://<username>:<password>@<host>/<db>") > >> > modparam("check_ua", "db_table", "check_ua") > >> > > >> > and somewhere in route section: > >> > > >> > if(!check_ua()) { > >> > xlog("L_ERR","Invalid UA DENIED: %fu, %is, %ua\n"); > >> > sl_send_reply("403", "Forbidden (Invalid UA)"); > >> > break; > >> > }; > >> > > >> > Voila. Until your Asterisk users will not find correct User-Agent > >> > they must use in their sip.conf - it will work... :) In my case - > >> > protection against bad symbols - it works even with asterisk... :) > >> > > >> > PS: not sure is that module can be found somewhere outside FreeBSD port, > >> > at least my google skills is not enough to ... > >> > However, both authors (Valentin Nechayev and Maxim Sobolev) read this list. > >> > > >> > >> _______________________________________________ > >> 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 > >

1 1

[Kamailio-Users] Having some issues with openser 1.2.3
by Krunal Patel 12 Dec '08

12 Dec '08

We are having setup like openser+radius+mediaproxy. Openser version is 1.2.3. When we started to send high volume calls , we get below mentioned ERRORs & WARNINGs. 1. /usr/local/sbin/openser[29869]: ERROR:tm:t_forward_nonack: discarding fwd for a cancelled transaction /usr/local/sbin/openser[29869]: ERROR:tm:w_t_relay: t_forward_nonack failed WARNING: script writer didn't release transaction 2. WARNING:tm:run_failure_handlers: no UAC or CANCEL support (1, 0) 3. /usr/local/sbin/openser[29870]: ERROR:nathelper:nh_timer: out of memory 4. /usr/local/sbin/openser[29870]: convert_rows: No memory left (openser crashed) As we were using default shared memory for openser, we increased shared memory to maximum(2GB) to fix out of bound issue. We checked openser script for memory leacks using valgrind, but did not find any memory leack. During doing relay of CANCEL,in relay route t_on_failure was added. So we removed t_on_failure in relay route for CANCEL. So WARNING:tm:run_failure_handlers: no UAC or CANCEL support (1, 0) was fixed. Still we are facing, 1. /usr/local/sbin/openser[29869]: ERROR:tm:t_forward_nonack: discarding fwd for a cancelled transaction /usr/local/sbin/openser[29869]: ERROR:tm:w_t_relay: t_forward_nonack failed WARNING: script writer didn't release transaction 2. /usr/local/sbin/openser[29870]: ERROR:nathelper:nh_timer: out of memory 3. ERROR:usrloc:get_all_db_ucontacts: raw_query failed 4. rc_avpair_gen: received unknown attribute 80 of length 18: 0xA40AA6A78F04D67B03C75F8CA233F008 Will increasing private memory will solve all issues? Thanks in advance!! -- Krunal Patel

2 1

[Serusers] new_connection(): Access denied for user 'serro'
by caio 12 Dec '08

12 Dec '08

Hi all, I have this error when start ser (v0.9.7): 0(0) find_mod_export: found <db_update> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(0) get_connection(): Connection not found in the pool 0(0) release_connection(): Removing connection from the pool 0(0) get_connection(): Connection not found in the pool 0(0) release_connection(): Removing connection from the pool 0(0) DEBUG: init_mod: domain 0(0) domain - initializing 0(0) find_mod_export: found <db_use_table> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(0) find_mod_export: found <db_init> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(0) find_mod_export: found <db_close> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(0) find_mod_export: found <db_query> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(0) find_mod_export: found <db_raw_query> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(0) find_mod_export: found <db_free_result> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(0) find_mod_export: found <db_insert> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(0) find_mod_export: found <db_delete> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(0) find_mod_export: found <db_update> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(0) get_connection(): Connection not found in the pool 0(0) new_connection(): Access denied for user 'serro'@'localhost' to database 'ser' 0(0) db_init(): Could not create a connection 0(0) ERROR:domain_db_init: cannot initialize database connection 0(0) init_mod(): Error while initializing module domain ERROR: error while initializing modules 0(0) XLOG: destroy module ... Couriously, database name is not 'ser', i've changed its name on ser_mysql.sh. I also change on ser_mysql.sh DBNAME, USERNAME, and DEFAULT_PW. User 'serro' at this instance has its default password RO_PW (47serro11). The "ser_mysql.sh create" works, but then whan I run "ser -D -E" it fails. If I change 'serro' default password and run again ser_mysql (after deleting previous db installation), the failure is the the following: 0(0) get_connection(): Connection not found in the pool 0(0) new_connection(): Access denied for user 'serro'@'localhost' (using password: YES) 0(0) db_init(): Could not create a connection 0(0) ERROR:domain_db_init: cannot initialize database connection Here, access is denied, but seem to found correctly the new db name. Is it possible that 'serro', 'heslo', default password of serro, ser default db names, an similar values be hardcoded on ser binary? Any comments will be apreciatted.., thanks. caiogf

1 0

[Serusers] new_connection(): Access denied for user 'serro'
by caio 12 Dec '08

12 Dec '08

Hi all, I have this error when start ser (v0.9.7): 0(0) find_mod_export: found <db_update> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(0) get_connection(): Connection not found in the pool 0(0) release_connection(): Removing connection from the pool 0(0) get_connection(): Connection not found in the pool 0(0) release_connection(): Removing connection from the pool 0(0) DEBUG: init_mod: domain 0(0) domain - initializing 0(0) find_mod_export: found <db_use_table> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(0) find_mod_export: found <db_init> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(0) find_mod_export: found <db_close> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(0) find_mod_export: found <db_query> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(0) find_mod_export: found <db_raw_query> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(0) find_mod_export: found <db_free_result> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(0) find_mod_export: found <db_insert> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(0) find_mod_export: found <db_delete> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(0) find_mod_export: found <db_update> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(0) get_connection(): Connection not found in the pool 0(0) new_connection(): Access denied for user 'serro'@'localhost' to database 'ser' 0(0) db_init(): Could not create a connection 0(0) ERROR:domain_db_init: cannot initialize database connection 0(0) init_mod(): Error while initializing module domain ERROR: error while initializing modules 0(0) XLOG: destroy module ... Couriously, database name is not 'ser', i've changed its name on ser_mysql.sh. I also change on ser_mysql.sh DBNAME, USERNAME, DEFAULT_PW. User 'serro' at this instance has its default password RO_PW (47serro11). The "ser_mysql.sh create" works, but then whan I run "ser -D -E" if fails. If I change 'serro' default password and run again ser_mysql (after deleting previous db installation), the failure is the the following: 0(0) get_connection(): Connection not found in the pool 0(0) new_connection(): Access denied for user 'serro'@'localhost' (using password: YES) 0(0) db_init(): Could not create a connection 0(0) ERROR:domain_db_init: cannot initialize database connection Access is denied, but seem to found correctly the new db name. Is it possible that 'serro', 'heslo', default password of serro, ser default db names, an similar values be hardcoded on ser binary? Any comments will be apreciatted.., thanks. caiogf

1 0

Re: [Kamailio-Users] Kamalio Support for RFC 3323 " Privacy"
by ingdavidcespedes＠cable.net.co 12 Dec '08

12 Dec '08

----- Mensaje original ----- De: Iñaki Baz Castillo <ibc(a)aliax.net> Fecha: Jueves, Diciembre 11, 2008 4:52 pm Asunto: Re: [Kamailio-Users] Kamalio Support for RFC 3323 " Privacy" > El Jueves, 11 de Diciembre de 2008, ingdavidcespedes(a)cable.net.co > escribió:> SORRYYYYYYY, you were right. What i'm trying to say is > that if the UA > > insert the p-p-i and privacy headers, the proxy should understand > this and > > do what I say above. > > The user sends the request with: > From: Anonymous <sip:anonymous@XXXXXx> > P-Preferred-Identity: <sip:alice@domain.com> > Privacy: id > > Then the proxy knows who is by checking PPI header and could ask > for > credentiales. After it, the proxy would remove PPI before routing > the > request. > > If the proxy sends the request to a trusted node, it could add PAI > header: P-Asserted-Identity: <sip:alice@domain.com> > Privacy: id > > And the next element would remove it if it routes to an untrusted > node/endpoint. > > Agree with all that you say. Only that the "P-Preferred-Identity:" is optional. If it is not present, the proxy should add a predefined P-Asserted-Identity: header field, if it is going to send the request to a trusted node. But as you can see, this implies different possible cases. So it would be very nice if we can do all of this using some module or something like that, don't you think so? > -- > Iñaki Baz Castillo > > _______________________________________________ > Users mailing list > Users(a)lists.kamailio.org > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users >

4 3

[Kamailio-Users] CDRtool newbie
by BERGANZ François 12 Dec '08

12 Dec '08

Hello, Is there a simple doc to install CDRTool ? I need to install a simple prepaid system, but I dont really understand how to do! Thank you Cordialement, BERGANZ François P Pensez à l'Environnement, n'imprimez ce mail que si nécessaire.

2 2

Re: [Serusers] Issue with auth_identity
by jerome.herve＠orange-ftgroup.com 12 Dec '08

12 Dec '08

hello everyone, I still have an issue with auth_identity : I have this error: AUTH_IDENTITY VERIFIER: common name of certificate doesn't match host name The common name of my certificate is the name of my domain (used in Identity Info URL). I believe I've done the correct thing... Any idea guys ? Cheers, Jérôme HERVE -----Message d'origine----- De : Kovács Gergely [mailto:kg@testbike.hu] Envoyé : jeudi 11 décembre 2008 22:23 À : zze-HERVE Jerome RD-CORE-LAN Objet : Re: [Serusers] Issue with auth_identity Hi Jerome, I'm the one who developed auth_identity few years ago. I checked the source and it seems that your auth_identity was unable to decode the certificate that it had been successfully downloaded. How did you generate the certificates? Auth_identity supports only openssl! Of course I had it working :) You can find SER config snippets in the manual of the module: http://www.iptel.org/auth_identity_0 Shall I write you the openssl command line switches I used for generating certificates? Cheers, Gergo > -------- Original Message -------- > Subject: Re: [Serusers] Issue with auth_identity > Date: Wed, 10 Dec 2008 16:06:08 +0100 > From: <jerome.herve(a)orange-ftgroup.com> > To: <victor.pascual.avila(a)gmail.com> > CC: serusers(a)lists.iptel.org > > Hi, > Yes I've tried again with other certificates. > It happens before the vrfy_check_certificate... > During the function vrfy_get_certificate. > I really don't understand it. > If I put a wrong certificate name, I have a 404 Not Found so I believe > it sees the certificate. > But maybe it doesn't manage to download it. > Did you manage to make this working? > > > Jérôme HERVE > FT/NSM/RD/CORE/M2V/SID > tél. 02 96 05 27 41 > mob. 06 76 15 18 49 > jerome.herve(a)orange-ftgroup.com > > > -----Message d'origine----- > De : Victor Pascual Ávila [mailto:victor.pascual.avila@gmail.com] > Envoyé : mercredi 10 décembre 2008 14:13 À : zze-HERVE Jerome > RD-CORE-LAN Cc : serusers(a)lists.iptel.org Objet : Re: [Serusers] Issue > with auth_identity > > Hi Jerome, > I'm not sure about this but have you tried using other certificates? > > Cheers, > -Victor > > On Wed, Dec 10, 2008 at 11:30 AM, <jerome.herve(a)orange-ftgroup.com> wrote: >> Hello, >> >> I am trying to put in place auth_identity between 2 SER proxies and it >> doesn't work well. >> The first one manages to add identity and identity_info fields and to >> send the INVITE to the other proxy. >> But when the other proxy receive the message and does his tests there >> is an issue. >> It sends back a 436 Bad Identity Info. The error happens during the >> "vrfy_get_certificate" function (function which downloads the >> certificate thanks to identity_info URL). >> >> On my proxy logs, I can see this : AUTH_IDENTITY:retrieve_x509: DER >> Certificate error:0D0680A8:asn1 encoding >> routines:ASN1_CHECK_TLEN:wrong tag >> >> I really don't know what to do, do you have any idea? >> Thanks, >> Regards, >> >> Jérôme HERVE >> >> _______________________________________________ >> Serusers mailing list >> Serusers(a)lists.iptel.org >> http://lists.iptel.org/mailman/listinfo/serusers >> >> > > > > -- > Victor Pascual Ávila > _______________________________________________ > Serusers mailing list > Serusers(a)lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers

1 0

Re: [Kamailio-Users] Kamalio Support for RFC 3323 " Privacy"
by ingdavidcespedes＠cable.net.co 12 Dec '08

12 Dec '08

----- Mensaje original ----- De: ingdavidcespedes(a)cable.net.co Fecha: Jueves, Diciembre 11, 2008 4:43 pm Asunto: Re: [Kamailio-Users] Kamalio Support for RFC 3323 " Privacy" > > > ----- Mensaje original ----- > De: Alexandr Dubovikov <voip(a)start4.info> > Fecha: Viernes, Diciembre 5, 2008 1:13 pm > Asunto: Re: [Kamailio-Users] Kamalio Support for RFC 3323 " Privacy" > > > Iñaki Baz Castillo пишет: > > > El Viernes, 5 de Diciembre de 2008, Juha Heinanen escribió: > > > > > >> if caller needs privacy, then it is up to the UA to send > > anonymous from > > >> header together with p-p-i and privacy headers. > > >> > I Think this is wrong. The UA should ask for the privacy services, > an the proxy must offer this services. This means it must rewrite > the information that the UA is willing to keep private with > anonymous information, and keep track of it, so it can be replaced > when the response is received. SORRYYYYYYY, you were right. What i'm trying to say is that if the UA insert the p-p-i and privacy headers, the proxy should understand this and do what I say above. > > > > > > That would be so cool... Unfortunatelly I just know a SIP phone > > implementing > > > it: Twinkle. > > > > > > Other phones (as Linksys) when the user enables privacy during > a > > call, just > > > set the From Display-Name with "Anonymous" value, while the > From > > username > > > remains the real :( > > > > > > > > Yep, some UAC set "Anonymous" only in Display Name. But u can fix > > it > > using this code: > > > > $var(url) = $fu; > > if(is_present_hf("Privacy") && ($hdr(Privacy)=="id" || > > $hdr(Privacy)=="user") && search("(From|f):\s*\"?anonymous")) { > > uac_replace_from("Anonymous","sip:anonymous@anonymous.invalid"); > > if(!is_present_hf("P-Asserted-Identity")) { > > append_hf("P-Asserted-Identity: <$var(url)>\r\n"); }; > > } > > This is what i'm talking about!!!!, but you should check also if > the message already have a P-Asserted-Identity that was generated > before and remove it. > > And how it will know to which transaction it corresponds when the > response message comes. It will use the branch id, and the tags? It > doesn't matter that some URIs have been replaced with anonymous > information? > There should be an easier way to do this. > > > > > > With best regards, > > > > -- > > > > Alexandr Dubovikov * baron@iRC RusNet * shurik(a)start4.info > > AD1-UANIC * ICQ: 122351182 * http://www.start4.info > > > > > > > > _______________________________________________ > > Users mailing list > > Users(a)lists.kamailio.org > > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users > > > > > _______________________________________________ > Users mailing list > Users(a)lists.kamailio.org > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users >

3 5

Re: [Kamailio-Users] Kamalio Support for RFC 3323 " Privacy"
by ingdavidcespedes＠cable.net.co 12 Dec '08

12 Dec '08

> > Unfortunatelly I just know two implementations using PPI when > asking for > > privacy: Twinkle and Sofia stack. > > Do you know any hardphones that implement this? > > Regards. > > > > > > > _______________________________________________ > Users mailing list > Users(a)lists.kamailio.org > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users >

2 1

Re: [Kamailio-Users] Kamalio Support for RFC 3323 " Privacy"
by ingdavidcespedes＠cable.net.co 12 Dec '08

12 Dec '08

----- Mensaje original ----- De: Iñaki Baz Castillo <ibc(a)aliax.net> Fecha: Jueves, Diciembre 11, 2008 6:17 pm Asunto: Re: [Kamailio-Users] Kamalio Support for RFC 3323 " Privacy" > El Jueves, 11 de Diciembre de 2008, ingdavidcespedes(a)cable.net.co > escribió:> Agree with all that you say. Only that the "P-Preferred- > Identity:" is > > optional. If it is not present, the proxy should add a predefined > > P-Asserted-Identity: header field, if it is going to send the > request to a > > trusted node. > > Well, PPI is just used by the client if it wants to tell him proxy > who he is > (and doesn't want to indicate it in the From since theorically the > From > shouldn't be changed by the proxy). > > > > But as you can see, this implies different possible cases. So it > would be > > very nice if we can do all of this using some module or something > like> that, don't you think so? > > I already implement this exactly behaviour by examining the PPI > header instead > of From when PPI is present. Perhaps you mean a specific > module/functions for > this task? Could you describe these functions? > I don't know, something that makes this process easier. Maybe there is a need to create a module that can handle this. But meanwhile we can make a HowTo with the code and put it in the Wiki, I don't know!!!. > Regards. > > > -- > Iñaki Baz Castillo > > _______________________________________________ > Users mailing list > Users(a)lists.kamailio.org > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users >

1 0

Re: [Kamailio-Users] Kamalio Support for RFC 3323 " Privacy"
by ingdavidcespedes＠cable.net.co 11 Dec '08

11 Dec '08

----- Mensaje original ----- De: Alexandr Dubovikov <voip(a)start4.info> Fecha: Viernes, Diciembre 5, 2008 1:13 pm Asunto: Re: [Kamailio-Users] Kamalio Support for RFC 3323 " Privacy" > Iñaki Baz Castillo пишет: > > El Viernes, 5 de Diciembre de 2008, Juha Heinanen escribió: > > > >> if caller needs privacy, then it is up to the UA to send > anonymous from > >> header together with p-p-i and privacy headers. > >> I Think this is wrong. The UA should ask for the privacy services, an the proxy must offer this services. This means it must rewrite the information that the UA is willing to keep private with anonymous information, and keep track of it, so it can be replaced when the response is received. > > > > That would be so cool... Unfortunatelly I just know a SIP phone > implementing > > it: Twinkle. > > > > Other phones (as Linksys) when the user enables privacy during a > call, just > > set the From Display-Name with "Anonymous" value, while the From > username > > remains the real :( > > > > > Yep, some UAC set "Anonymous" only in Display Name. But u can fix > it > using this code: > > $var(url) = $fu; > if(is_present_hf("Privacy") && ($hdr(Privacy)=="id" || > $hdr(Privacy)=="user") && search("(From|f):\s*\"?anonymous")) { > uac_replace_from("Anonymous","sip:anonymous@anonymous.invalid"); > if(!is_present_hf("P-Asserted-Identity")) { > append_hf("P-Asserted-Identity: <$var(url)>\r\n"); }; > } This is what i'm talking about!!!!, but you should check also if the message already have a P-Asserted-Identity that was generated before and remove it. And how it will know to which transaction it corresponds when the response message comes. It will use the branch id, and the tags? It doesn't matter that some URIs have been replaced with anonymous information? There should be an easier way to do this. > > > With best regards, > > -- > > Alexandr Dubovikov * baron@iRC RusNet * shurik(a)start4.info > AD1-UANIC * ICQ: 122351182 * http://www.start4.info > > > > _______________________________________________ > Users mailing list > Users(a)lists.kamailio.org > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users >

1 0

Re: [Kamailio-Users] Kamailio in Red Hat 4 with mysql and carrierroute]
by ingdavidcespedes＠cable.net.co 11 Dec '08

11 Dec '08

Yes. You should download kamailio-1.4.1-notls_src.tar.gz, and when you compile it, you should write make all include_modules="db_mysql" instead of make all include_modules="mysql". It has changed for Kamailio. ----- Mensaje original ----- De: Juan Asencio <juan(a)asencio.dk> Fecha: Lunes, Diciembre 8, 2008 4:15 pm Asunto: Re: [Kamailio-Users] Kamailio in Red Hat 4 with mysql and carrierroute] > Juan Asencio wrote: > > Henning Westerholt wrote: > > > >> On Monday 08 December 2008, Juan Asencio wrote: > >> > >> > >>> Hi, I'm trying to install from source Kamailio on Red Hat 4, > and I need > >>> to include mysql as a database and carrierroute. > >>> > >>> When I check on the directory of modules, I can't see mysql.so or > >>> carrierroute.so, how can I include them? > >>> > >>> Best regards, > >>> > >>> > >> Hi Juan, > >> > >> have you compiled and installed the db_mysql and the > carrierroute module? > >> There excluded in the default installation, because they need > some extra > >> libraries. > >> > >> Cheers, > >> > >> Henning > >> > >> > > Hi again, I have another question :) > > > > I have download the kamailio-1.4.1-notls_linux_i386.tar.gz > > Put it on the directory: /usr/src and there I did: tar zxvf > kamai...tar.gz> A list of directories and files are created, but I > can't find the > > Makefile and I can't "make all" or "make" anything. > > > > In my small Linux experience, when I tar xvf... something.tar.gz > a > > directory of something is created and then I usually can find the > > makefile there. > > > > Why I can't find it now? I'm trying to follow the instructions on > > http://www.kamailio.org/mos/view/Installation-Notes/ but I can't > do it. > > > > Can anyone please give some suggestions? > > > > Thanks in advance, > > > > Juan.- > > > > > > > > _______________________________________________ > > Users mailing list > > Users(a)lists.kamailio.org > > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users > > > Hi everybody, > > I figure it out :D sorry for the trouble. I was downloading the > wrong file. > > Cheers!!! > > Juan.- > > _______________________________________________ > Users mailing list > Users(a)lists.kamailio.org > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users >

1 0

[Serusers] Help with SIPSAK
by Steven C. Blair 11 Dec '08

11 Dec '08

I currently use sipsak 0.8.8 for a variety of tasks however I now need to use sipsak to start, maintain and end a SIP session. I'd like to send an INVITE, authenticate, check for a 200 OK, send a refer then a bye to remove myself from the call. I cannot get this to work. I've tried sipsak with the -l, -G, -u, -a and -s options in various combinations without success. Does anyone have any thoughts on how I can accomplish this task? Thanks,Steve Senior Network Engineer, Information Systems and Computing Networking and Telecommunications , Suite 221A /6228 University of Pennsylvania Voice:215-573-8396 FAX:215-898-9348

2 2

[Serusers] Help with SIPSAK
by Steven C. Blair 11 Dec '08

11 Dec '08

I currently use sipsak 0.8.8 for a variety of tasks however I now need to use sipsak to start, maintain and end a SIP session. I'd like to send an INVITE, authenticate, check for a 200 OK, send a refer then a bye to remove myself from the call. I cannot get this to work. I've tried sipsak with the -l, -G, -u, -a and -s options in various combinations without success. Does anyone have any thoughts on how I can accomplish this task? Thanks,Steve Senior Network Engineer, Information Systems and Computing Networking and Telecommunications , Suite 221A /6228 University of Pennsylvania Voice:215-573-8396 FAX:215-898-9348

1 0

[Serusers] ser routing
by Netadmin 11 Dec '08

11 Dec '08

Hello, I want to route a phone number to different routes on different hours. If the time is later then 17 i'll route to route(1), else route to route(2). How can i do this? is there a way to get time in ser.cfg? Or i need to make a separate module? Thanks.

5 6

[Kamailio-Users] is_present_hf function
by Antonio Reale 10 Dec '08

10 Dec '08

Hi all, I have a problem with the is_present_hf function from TEXTOPS module. In the script (openser 1.2.3-notls) I have: --- if(is_present_hf("Proxy-Authorization")) { xlog("L_ERR", "Proxy-Authorization header present\n"); consume_credentials(); } --- When the proxy receives the BYE message I see in the log: Dec 10 16:00:54 sipsvr /usr/sbin/openser[12846]: Proxy-Authorization header present Dec 10 16:00:54 sipsvr /usr/sbin/openser[12846]: consume_credentials(): No authorized credentials found (error in scripts) Tracing the call I don't see any Proxy-Authorization header in the BYE message. Why the function is_present_hf returns true? Attached you will find debug messages from Openser/Kamailio and the BYE. I see the problem using Kapanga softphone, but the same problem occurs in production environment with different CPEs (for instance Linksys SPA2102). The strange thing is that it occurs only when kapanga is the caller (and hungup) and not when it is the callee (and hungup). Using wireshark I see that the BYE is the same in both situation. How can I debug this problem? Thanks a lot. Regards, Antonio.

3 2

[Serusers] Issue with auth_identity
by jerome.herve＠orange-ftgroup.com 10 Dec '08

10 Dec '08

Hello, I am trying to put in place auth_identity between 2 SER proxies and it doesn't work well. The first one manages to add identity and identity_info fields and to send the INVITE to the other proxy. But when the other proxy receive the message and does his tests there is an issue. It sends back a 436 Bad Identity Info. The error happens during the "vrfy_get_certificate" function (function which downloads the certificate thanks to identity_info URL). On my proxy logs, I can see this : AUTH_IDENTITY:retrieve_x509: DER Certificate error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag I really don't know what to do, do you have any idea? Thanks, Regards, Jérôme HERVE

2 2

[Kamailio-Users] preparing kamailio-1.4.3, planning for 1.5.0
by Henning Westerholt 10 Dec '08

10 Dec '08

Hi, according to our last IRC meeting [1] we want to release a minor release for the 1.4 branch in the next days. We've did already over 40 changes in this branch, many of them for important bugs, so i propose the next thursday, the 11th december as the date for 1.4.3. So if you have any important backports or other fixes that should go into this release, please commit them until this day. While already on the release topic, the code freeze period for the 1.5.0 release will be start in the mid of Januar, roughly in about 6 weeks from now. So if you like to contribute something that should be included in this release, please commit it to our repository or upload the patch to the tracker for review. Already finished features and the roadmap can be found as usual in our wiki at [2, 3]. If you like to give the new features a try, then you find prebuild packages for several debian releases here [4]. Please report any bugs you find to our developer list. Best regards, Henning [1] http://www.kamailio.org/mos/view/News/NewsItem/IRC-Devel-Meeting-Summary---… [2] http://www.kamailio.org/dokuwiki/doku.php/features:new-in-1.5.x [3] http://www.kamailio.org/dokuwiki/doku.php/roadmap:1.5.x [4] devel.kamailio.org

5 8

[Kamailio-Users] important: gflags, options, uri module functionality moved
by Henning Westerholt 09 Dec '08

09 Dec '08

Hi, in order to reduce the number of modules that needs to be maintained we integrated several small modules into existing ones. This applies only to the devel (trunk) version. No functionality was removed, it can be now just found in a different place. 1. gflags module The functionality of this module was integrated into the cfgutils module. The internal functionality, function names and MI commands are the same, the parameter “initial” was renamed to “initial_gflags”. 2. options module The functionality of this module was integrated into the siputils module. The function name was not changed, all parameters were prefixed with the "options_” string. 3. uri module The functionality of this module was integrated into the siputils module. The function names were not changed, internal functionality is the same. So starting from the release 1.5 you'll need to fix your "loadmodule" statements and some parameter prefixes in your config if you use one of the mentioned modules. Documentation for the functions can be found in the usual place [1, 2]. Cheers, Henning [1] http://www.kamailio.org/docs/modules/devel/cfgutils.html [2] http://www.kamailio.org/docs/modules/devel/siputils.html

4 10

[Kamailio-Users] no free tcp receiver
by Gawith 09 Dec '08

09 Dec '08

Hi all, My OpenSER system seems to run out of TCP handlers all the time. It looks to me that I need two child processes for each local IP and peer combination, because to and back communication do not use the same TCP channel. I have a lot of TCP clients which would lead to more than 100 child processes. Does it make sense to reduce tcp_connection_lifetime? This would increase TCP overhead, but would allow me to have fewer child processes, right? Any help is welcome. Thanks guys! Regards

2 8

[Kamailio-Users] Xcap-diff publishing?
by John Stalh 09 Dec '08

09 Dec '08

Hello, I am trying to setup Kamailio to publish xcap-diff payload to a client. However, the xcap-diff event is not supported (receives a SIP 489 answer), even though it says Kamailio supports it. What am I missing? How does the mi_xmlrpc module works? For reference, I use Openxcap and it is correctly (theorically at least) set to use Kamailio. Best regards, John

2 1

[Kamailio-Users] new features: $T_req(pv) and $T_rpl(pv)
by Daniel-Constantin Mierla 09 Dec '08

09 Dec '08

Hello, the TM module introduces two new features: - access to SIP request attributes while processing a reply belonging to same transaction - access to SIP reply attributes while processing a request belonging to same transaction Functionalities come as pseudo-variables, $T_req(pv) and $T_rpl(pv) - where pv can be any pseudo-variable, check documents at: http://www.kamailio.org/dokuwiki/doku.php/pseudovariables:devel#tm_module_p… The new pseudo-variables can be used: - in failure_route to get the attributes of the reply causing the failure route. You can take decisions what to do with the request based on reply details - in onreply_route to get the attributes of the request. you can take decision what to do with the reply based on request attributes. - in acc to store data from reply - in C code (modules) Note that couple of PV are disabled for these cases (PV will return null) - these are the PV that alter/depend on the context of the processed message, like $Ts, $Tf (but you can use $TS and $TF), $time, destination set attributes. The $avp() will be current avps, as they are stored in a global list. Also, in case there is a timeout or other reply generated by kamailio itself, $T_rpl(pv) will return null as there is no real reply structure behind. Example, print the source ip of the reply in failure route: failure_route[1] { xlog("reply received from: $T_rpl($si)\n"); } Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

1 0

[Serusers] How to use the variable "src_ip"?
by Raman Chan 09 Dec '08

09 Dec '08

In the ser.cfg, we can output src_ip(%is) with "xlog" but how can I import this variable into the module of myself? Thanks, Raman

1 0

[Serusers] SEMS 1.1.0 rc1 available
by Stefan Sayer 08 Dec '08

08 Dec '08

Hello, as promised there is a first release candidate for the 1.1 release of the SIP Express Media Server available: Source: http://ftp.iptel.org/pub/sems/1.1/rc1/src/sems-1.1.0-rc1.tar.gz Debian packages: http://ftp.iptel.org/pub/sems/1.1/rc1/packages/debian/ This RC1 was created from SVN rev 1193. With the version 1.1 SEMS gets - DSM state machine scripting (it's cool!) - an (experimental) ISDN gateway module - binrpc: MT (SER->) and connection pool (->SER) - MT xmlrpc server - controlled server shutdown - improved logging - g722 in 8khz compat mode - out of dialog request handling for modules & dialogs without sessions - audio file autorewind, AmAudio mixing - SIP and media IP separately configurable - UID/DID support for voicemail/-box/annrecorder - and quite some bugs and mem leaks fixed, documentation, etc. You are welcome to test this release candidate, and give feedback on the SEMS mailing list (sems(a)iptel.org), the semsdev list (semsde(a)iptel.org), or the bug tracker: http://tracker.iptel.org. Thanks to all contributions and patches, this time from Stefan Sayer, Raphael Coeffic, Grzegorz Stanislawski, Bogdan Pintea, Greger Teigre, Rui Jin Zheng, Alfred E Heggestad, Juha Heinanen, Peter Lemenkov, Robert Szokovacs, Jeremy A, Alex Gradinar Best Regards Stefan Sayer -- Stefan Sayer VoIP Services stefan.sayer(a)iptego.com www.iptego.com IPTEGO GmbH Am Borsigturm 40 13507 Berlin Germany Amtsgericht Charlottenburg, HRB 101010 Geschaeftsfuehrer: Alexander Hoffmann

1 0

Re: [Kamailio-Users] Kamailio in Red Hat 4 with mysql and carrierroute]
by Juan Asencio 08 Dec '08

08 Dec '08

Henning Westerholt wrote: > On Monday 08 December 2008, Juan Asencio wrote: > >> Hi, I'm trying to install from source Kamailio on Red Hat 4, and I need >> to include mysql as a database and carrierroute. >> >> When I check on the directory of modules, I can't see mysql.so or >> carrierroute.so, how can I include them? >> >> Best regards, >> > > Hi Juan, > > have you compiled and installed the db_mysql and the carrierroute module? > There excluded in the default installation, because they need some extra > libraries. > > Cheers, > > Henning > Hi again, I have another question :) I have download the kamailio-1.4.1-notls_linux_i386.tar.gz Put it on the directory: /usr/src and there I did: tar zxvf kamai...tar.gz A list of directories and files are created, but I can't find the Makefile and I can't "make all" or "make" anything. In my small Linux experience, when I tar xvf... something.tar.gz a directory of something is created and then I usually can find the makefile there. Why I can't find it now? I'm trying to follow the instructions on http://www.kamailio.org/mos/view/Installation-Notes/ but I can't do it. Can anyone please give some suggestions? Thanks in advance, Juan.-

1 1

[Kamailio-Users] Kamailio in Red Hat 4 with mysql and carrierroute
by Juan Asencio 08 Dec '08

08 Dec '08

Hi, I'm trying to install from source Kamailio on Red Hat 4, and I need to include mysql as a database and carrierroute. When I check on the directory of modules, I can't see mysql.so or carrierroute.so, how can I include them? Best regards, Juan.-

2 1

[Kamailio-Users] using "substr()" function from TEXTOPS in "onreply_route" block
by Alex R.S.M 08 Dec '08

08 Dec '08

Hi, I was wondering if anyone has used "substr()" function from TEXTOPS in "onreply_route" block. This function works fine in "route" and "branch_route" blocks. However, it creates duplicate fields (instead of substituting) when being used in "onreply_route" blocks. I need to modify FROM field in "onreply_route" block. As far as I know, "uac_replace_from()" function works only in request_route block, so my only option is to use "substr()". Thanks, Alex R _________________________________________________________________ Proud to be a PC? Show the world. Download the “I’m a PC” Messenger themepack now. hthttp://clk.atdmt.com/MRT/go/119642558/direct/01/

3 3

[Kamailio-Users] Route-problem, no 487 sent
by Magnus Burman 08 Dec '08

08 Dec '08

Something fishy is going on with my routing. If my SIP UA (91.XXX.XXX.80) hangs up before the receiving end (pstn on 212.YYY.YYY.84) answers, it keeps ringing forever. Below is my routing in regards to CANCEL and the ngrep output. If I understand things correctly, I should send a 487 Request Terminated back to the initiating UA (sip), and I would get a 487 Request Terminated from the pstn provider. I'm not sending the 487 to the UA, and I'm guessing I close the session before my pstn provider sends one to me, so I don't see it with ngrep? The big question is ofcourse what I need to do to get on track, sending the appropriate 487? route: -- #CANCEL processing if (is_method("CANCEL") || is_method("ACK")) { if (t_check_trans()) { setflag(1); if(!t_relay()) { sl_reply_error(); } } exit; }; ngrep output, comments starting with #: -- U 91.XXX.XXX.80:5060 -> 91.ZZZ.ZZZ.9:5060 CANCEL sip:6--------@91.ZZZ.ZZZ.9 SIP/2.0 Via: SIP/2.0/UDP 91.XXX.XXX.80:5060;branch=z9hG4bK1e22091bbd2d0a9b9e0f8de6553d2c27 From: "349--------"<sip:user1@91.ZZZ.ZZZ.9>;tag=XG6525p2-b915854d-1373157639 To: <sip:6--------@91.ZZZ.ZZZ.9> Call -ID: 6C8F-F261-374702698-E353C7B05C17-0006(a)91.XXX.XXX.80 CSeq: 10 CANCEL Max-Forwards: 70 User-Agent: XAVi/XG6525p2-1.6.7 Content-Length: 0 U 91.ZZZ.ZZZ.9:5060 -> 91.XXX.XXX.80:5060 SIP/2.0 200 canceling Via: SIP/2.0/UDP 91.XXX.XXX.80:5060;branch=z9hG4bK1e22091bbd2d0a9b9e0f8de6553d2c27 From: "349--------"<sip:user1@91.ZZZ.ZZZ.9>;tag=XG6525p2-b915854d-1373157639 To: <sip:6--------@91.ZZZ.ZZZ.9>;tag=bbd8f31c58bc6a3266ec5509a254d55b-cb96 Call-ID: 6C8F-F261-374702698-E353C7B05C17-0006(a)91.XXX.XXX.80 CSeq: 10 CANCEL Server: Kamailio (1.4.1-notls (i386/linux)) Content-Length: 0 # 487 Request Terminated from 91.ZZZ.ZZZ.9 to 91.XXX.XXX.80 ?? U 91.ZZZ.ZZZ.9:5060 -> 212.YYY.YYY.84:5060 CANCEL sip:346--------@212.YYY.YYY.84 SIP/2.0 Via: SIP/2.0/UDP 91.ZZZ.ZZZ.9;branch=z9hG4bKe214.208c19e6.0 From: "349--------"<sip:user1@91.ZZZ.ZZZ.9>;tag=XG6525p2-b915854d-1373157639 Call-ID: 6C8F-F261-374702698-E353C7B05C17-0006(a)91.XXX.XXX.80 To: <sip:6--------@91.ZZZ.ZZZ.9> CSeq: 10 CANCEL Max-Forwards: 70 User-Agent: Kamailio (1.4.1-notls (i386/linux)) Content-Length: 0 U 212.YYY.YYY.84:5060 -> 91.ZZZ.ZZZ.9:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 91.ZZZ.ZZZ.9:5060;branch=z9hG4bKe214.208c19e6.0 To: <sip:6--------@91.ZZZ.ZZZ.9>;tag=a439d513 From: "349--------" <sip:user1@91.ZZZ.ZZZ.9>;tag=XG6525p2-b915854d-1373157639 Call-ID: 6C8F-F261-374702698-E353C7B05C17-0006(a)91.XXX.XXX.80 CSeq: 10 CANCEL User-Agent: ENS2.2.122-IS2 Content-Length: 0 # 487 Request Terminated from 212.YYY.YYY.84 to 91.ZZZ.ZZZ.9 ?? Best Regards, Magnus

1 0

[Kamailio-Users] new feature: re.subst transformation
by Daniel-Constantin Mierla 08 Dec '08

08 Dec '08

Hello, using the latest development work and the newest pseudo-variable&transformation framework (http://lists.kamailio.org/pipermail/users/2008-December/020918.html), the textops module offers a new class of transformation for regular expressions. By now, it implements {re.subst,expression} - ability to do Perl-like substitution of string value pseudo-variables: http://www.kamailio.org/dokuwiki/doku.php/transformations:devel#re.subst_ex… Here is an example to extract username part from R-URI using this transformation: $var(user) = $(ru{re.subst,/^sip:(.*)@(.*)/\1/}); Now, the subst operation becomes very handy, old tricks to copy in R-URI and use subst*() functions from textops module, or copy in avps and use avpops module are no longer required. This implementation can be used as example by developers to learn how to export new transformations from other modules. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

1 0

[Kamailio-Users] important: transformations moved from core to pv module
by Daniel-Constantin Mierla 08 Dec '08

08 Dec '08

Hello, the pseudo-variable and transformation framework in core has been completed for upcoming v1.5.0 of Kamailio (OpenSER). The core has now only API to register, parse name, evaluate and set values for PV&T. All specific implementations have moved to PV module: http://kamailio.org/docs/modules/devel/pv.html The current architecture provides a flexible way to enhance the number PV&T available in config file without affecting the stability and the performance of core and main modules. As this number increased a lot, and will grow more, the API changed the indexing from a list to a hash table, offering faster lookup and quicker shorter up time. With this work done, a new functionality is available for developers: - they can export new transformations from their module. As example, check the pv or textops (new transformation to be announced in separate message) modules. The system is simple, you have to implement a function to parse the name of transformation and its parameter, plus a function to evaluate a transformation. Now core got some clean up, not that fat anymore, implementation of about 100 pseudo-variables and over 30 transformations was moved out (couple of thousands lines of code). This work is part of the efforts to increase the stability, performance and flexibility of the core, so that specific implementations do not affect typical use cases. As final note, remember to load the pv module from now on if you work with/need old core pseudo-variables or transformations. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

1 0

[Kamailio-Users] new module: sqlops - sql operations
by Daniel-Constantin Mierla 08 Dec '08

08 Dec '08

Hello, the devel version (to be released as 1.5.0 in Q1 2009) includes now a new module: sqlops. It can be used to do raw sql queries in config file and play with the result data. Key features: * /many DB connections/ - the module can connect to many databases on different servers using different DB driver modules (mysql, postgres, ...) at the same time. * /many DB results/ - the module can store many results of different SQL queries in separate structures at the same time. Thus is possible to work in parallel with several DB results. * /access via pseudo-variables/ - the content of SQL query result is accessible via pseudo-variables. * /array indexes/ - fast access to result values via array possition: [row,column]. * /persistence in process space/ - a result can be used many times in same worker process. Query once, use many times. Here is an example of fetching and printing the content of a table: ... modparam("sqlops","sqlcon","ca=>mysql://openser:abc@localhost/openser") ... sql_query("ca", "select * from domain", "ra"); xlog("rows: $dbr(ra=>rows) cols: $dbr(ra=>cols)\n"); if($dbr(ra=>rows)>0) { $var(i) = 0; while($var(i)<$dbr(ra=>cols)) { xlog("--- SCRIPT: column[$var(i)] = $dbr(ra=>colname[$var(i)])\n"); $var(i) = $var(i) + 1; } $var(i) = 0; while($var(i)<$dbr(ra=>rows)) { $var(j) = 0; while($var(j)<$dbr(ra=>cols)) { xlog("[$var(i),$var(j)] = $dbr(ra=>[$var(i),$var(j)])\n"); $var(j) = $var(j) + 1; } $var(i) = $var(i) + 1; } } sql_result_free("ra"); ... Other advantages than the ones listed above against avp_db_query(): - does not mess up fields position if the value in db is null - use private memory, no locking - does not iterate through linked (avp) list to get each field, direct reference to each data structure in result array, thus much faster. More info at: http://kamailio.org/docs/modules/devel/sqlops.html Testing and feedback is appreciated. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

1 0

Re: [Serusers] Deadly embrace with rtpproxy - Is it necessary? Can it be turned off?
by Frank Durda IV 06 Dec '08

06 Dec '08

Greger Viken Teigre wrote: > Hi Frank, the behavior of rtpproxy is like that because you want to send > rtp back on source port if it has changed from the sdp, which often > happens > behind a nat. > Have you tried changing active media in sdp? The gateway has the same > active media mode as rtpproxy. > g-) I don't believe I understand what you are asking re: active media. Are you talking about some control I can set in SER or rtpproxy? Because those are the only knobs available to me. The company sending the call to us doesn't want to change settings on their equipment to accomodate what they consider to be our incompatibility (what rtpproxy is doing), as what they are doing (not sending audio until they receive audio from us) isn't a problem when they send calls to other carriers. If you are suggesting something I have SER patch into the 183/200 SDP payload to trick the calling system to send audio without waiting to see some audio from us, what exactly are you suggesting be added and how would that be done? As a FYI, the PSTN gateway switch behind our SER system has virtually no SIP controls, as the first thing it does is make the call look as much like a TDM call as possible, right down to assigning a pseudo trunk number for the call to be carried in. Of course, this is the device that is happily sending RTP audio which rtpproxy is throwing away, so I don't think I can fix the problem from that side even if there was a knob to change something since this side is already working. And yes, you can create this same problem that I am reporting by having the audio for a call pass between two SER systems with rtpproxy on both with no NAT present whatsoever (no re-routing of audio, just bridging isolated networks). Neither rtpproxy daemon will blink until the other does, and so audio never works. This has got to be wrong. I'll point out that when I reported this a month of two ago, someone on the list came out and said rtpproxy does not do what I was reporting, can't do this, always passes audio in a given direction the instant the SDP payload for that direction passes through SER. I don't find that to be the case and the demonstration proves that the behavior is different. I also don't understand the comment above about sending back to the source port. From what I can see, rtpproxy opens four separate ports, two on each interface, one for incoming and one for outgoing on each I would assume. If not, then that would be a different bug as rtpproxy is opening twice the number of ports it actually needs. (I think it is using all four in the two-interface mode.) Please clarify what you are saying/suggesting if you can. Examples appreciated. Thanks.

2 1

[Kamailio-Users] Kamalio Support for RFC 3323 " Privacy"
by ingdavidcespedes＠cable.net.co 05 Dec '08

05 Dec '08

Hi Is there any way (special module, or something like that) to implement RFC 3323 in Kamailio. Or do I have to do it manually, by changing the header fields that require privacy and change them for something like ("Anonymous" <sip:anonymous@anonymous.invalid>) and keep the relation of this new URI with the original one, in a separate table of my database?. How can I do this in a more easy way?. David Cespedes

4 4

[Kamailio-Users] Interfacing error with textdb module
by Dhaval Shah 05 Dec '08

05 Dec '08

Hi, I am new to SIP - Kamailio. I am trying to run Kamailion (version 1.4.2 Latest) SIP server with authantication using dbtext module. I have compiled and installed Kamalio and required modules sucessfully. When I run the Kamalio after configuration I received error from "find_mod_export". ---------------------------------------------------------------------------------------------------------------------------------------------------------- "Debug log" Dec 5 19:33:42 [24301] DBG:core:yyparse: loading module //lib/kamailio/modules/db_text.so Dec 5 19:33:42 [24301] DBG:core:yyparse: loading module //lib/kamailio/modules/sl.so Dec 5 19:33:42 [24301] DBG:core:yyparse: loading module //lib/kamailio/modules/tm.so Dec 5 19:33:42 [24301] DBG:core:register_module: register_pv: tm Dec 5 19:33:42 [24301] DBG:core:pv_add_extra: extra items list is not initialized Dec 5 19:33:42 [24301] DBG:core:yyparse: loading module //lib/kamailio/modules/rr.so Dec 5 19:33:42 [24301] DBG:core:yyparse: loading module //lib/kamailio/modules/maxfwd.so Dec 5 19:33:42 [24301] DBG:core:yyparse: loading module //lib/kamailio/modules/usrloc.so Dec 5 19:33:42 [24301] DBG:core:yyparse: loading module //lib/kamailio/modules/registrar.so Dec 5 19:33:42 [24301] DBG:core:yyparse: loading module //lib/kamailio/modules/textops.so Dec 5 19:33:42 [24301] DBG:core:yyparse: loading module //lib/kamailio/modules/mi_fifo.so Dec 5 19:33:42 [24301] DBG:core:yyparse: loading module //lib/kamailio/modules/uri_db.so Dec 5 19:33:42 [24301] DBG:core:yyparse: loading module //lib/kamailio/modules/uri.so Dec 5 19:33:42 [24301] DBG:core:yyparse: loading module //lib/kamailio/modules/xlog.so Dec 5 19:33:42 [24301] DBG:core:register_module: register_pv: xlog Dec 5 19:33:42 [24301] DBG:core:yyparse: loading module //lib/kamailio/modules/acc.so Dec 5 19:33:42 [24301] DBG:core:yyparse: loading module //lib/kamailio/modules/auth.so Dec 5 19:33:42 [24301] DBG:core:yyparse: loading module //lib/kamailio/modules/auth_db.so Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: db_text matches module db_text Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: found <db_mode> in module db_text [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: mi_fifo matches module mi_fifo Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: found <fifo_name> in module mi_fifo [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: rr matches module rr Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: found <enable_full_lr> in module rr [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: rr matches module rr Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: found <append_fromtag> in module rr [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: registrar matches module registrar Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: found <method_filtering> in module registrar [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: uri_db matches module uri_db Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: found <use_uri_table> in module uri_db [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: uri_db matches module uri_db Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: found <db_url> in module uri_db [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: acc matches module acc Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: found <early_media> in module acc [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: acc matches module acc Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: found <report_ack> in module acc [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: acc matches module acc Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: found <report_cancels> in module acc [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: acc matches module acc Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: found <detect_direction> in module acc [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: acc matches module acc Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: found <failed_transaction_flag> in module acc [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: acc matches module acc Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: found <log_flag> in module acc [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: acc matches module acc Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: found <log_missed_flag> in module acc [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: acc matches module acc Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: found <db_flag> in module acc [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: acc matches module acc Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: found <db_missed_flag> in module acc [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: usrloc matches module usrloc Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: found <db_mode> in module usrloc [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: usrloc matches module usrloc Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: found <db_mode> in module usrloc [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: usrloc matches module usrloc Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: found <db_url> in module usrloc [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: auth_db matches module auth_db Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: found <calculate_ha1> in module auth_db [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: auth_db matches module auth_db Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: found <password_column> in module auth_db [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: auth_db matches module auth_db Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: found <db_url> in module auth_db [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <mf_process_maxfwd_header>(1) in module maxfwd [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <sl_send_reply>(2) in module sl [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <has_totag>(0) in module uri [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <loose_route>(0) in module rr [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <is_method>(1) in module textops [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <is_method>(1) in module textops [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <t_check_trans>(0) in module tm [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <t_relay>(0) in module tm [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <sl_send_reply>(2) in module sl [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <is_method>(1) in module textops [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <t_check_trans>(0) in module tm [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <t_relay>(0) in module tm [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <t_check_trans>(0) in module tm [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <proxy_authorize>(2) in module auth_db [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <proxy_challenge>(2) in module auth [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <check_from>(0) in module uri_db [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <sl_send_reply>(2) in module sl [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <consume_credentials>(0) in module auth [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <is_method>(1) in module textops [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <record_route>(0) in module rr [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <is_method>(1) in module textops [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <append_hf>(1) in module textops [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <is_method>(1) in module textops [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <sl_send_reply>(2) in module sl [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <is_method>(1) in module textops [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <www_authorize>(2) in module auth_db [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <www_challenge>(2) in module auth [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <check_to>(0) in module uri_db [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <sl_send_reply>(2) in module sl [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <save>(1) in module registrar [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <sl_reply_error>(0) in module sl [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <sl_send_reply>(2) in module sl [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <lookup>(1) in module registrar [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <t_newtran>(0) in module tm [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <t_reply>(2) in module tm [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <sl_send_reply>(2) in module sl [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <is_method>(1) in module textops [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <t_on_branch>(1) in module tm [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <t_on_reply>(1) in module tm [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <t_on_failure>(1) in module tm [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <t_relay>(0) in module tm [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <sl_reply_error>(0) in module sl [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <xlog>(1) in module xlog [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <xlog>(1) in module xlog [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <t_was_cancelled>(0) in module tm [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:socket2str: <udp:127.0.0.1:5060> Dec 5 19:33:42 [24301] WARNING:core:fix_socket_list: could not rev. resolve 192.168.40.35 Dec 5 19:33:42 [24301] DBG:core:socket2str: <udp:192.168.40.35:5060> Dec 5 19:33:42 [24301] DBG:core:socket2str: <tcp:127.0.0.1:5060> Dec 5 19:33:42 [24301] WARNING:core:fix_socket_list: could not rev. resolve 192.168.40.35 Dec 5 19:33:42 [24301] DBG:core:socket2str: <tcp:192.168.40.35:5060> Listening on udp: 127.0.0.1 [127.0.0.1]:5060 udp: 192.168.40.35 [192.168.40.35]:5060 tcp: 127.0.0.1 [127.0.0.1]:5060 tcp: 192.168.40.35 [192.168.40.35]:5060 Aliases: tcp: localhost:5060 udp: localhost:5060 Dec 5 19:33:42 [24301] WARNING:core:main: no fork mode and more than one listen address found(will use only the first one) Dec 5 19:33:42 [24301] DBG:core:fm_malloc_init: F_OPTIMIZE=16384, /ROUNDTO=2048 Dec 5 19:33:42 [24301] DBG:core:fm_malloc_init: F_HASH_SIZE=2067, fm_block size=16560 Dec 5 19:33:42 [24301] DBG:core:fm_malloc_init: params (0xb5fdc000, 33554432), start=0xb5fdc000 Dec 5 19:33:42 [24301] DBG:core:shm_mem_init_mallocs: success Dec 5 19:33:42 [24301] INFO:core:init_tcp: using epoll_lt as the TCP io watch method (auto detected) Dec 5 19:33:42 [24301] DBG:core:set_core_dump: core dump limits set to 4294967295 Dec 5 19:33:42 [24301] NOTICE:core:main: version: kamailio 1.4.2-notls (i386/linux) Dec 5 19:33:42 [24301] INFO:core:main: using 32 Mb shared memory Dec 5 19:33:42 [24301] INFO:core:main: using 1 Mb private memory per process Dec 5 19:33:42 [24301] DBG:core:add_avp_galias: registering <serial_branch> for avp id <16725044> Dec 5 19:33:42 [24301] DBG:core:init_stats_collector: statistics manager successfully initialized Dec 5 19:33:42 [24301] DBG:core:init_mod: initializing module db_text Dec 5 19:33:42 [24301] DBG:core:init_mod: initializing module sl Dec 5 19:33:42 [24301] INFO:sl:mod_init: Initializing StateLess engine Dec 5 19:33:42 [24301] DBG:core:MD5StringArray: MD5 calculated: f8f2ab2c1295e90ed7dbb499b30f44b2 Dec 5 19:33:42 [24301] DBG:core:init_mod: registering stats for sl Dec 5 19:33:42 [24301] DBG:core:init_mod: initializing module tm Dec 5 19:33:42 [24301] INFO:tm:mod_init: TM - initializing... Dec 5 19:33:42 [24301] DBG:tm:init_callid: Call-ID initialization: '35cb5f3b' Dec 5 19:33:42 [24301] DBG:tm:lock_initialize: lock initialization started Dec 5 19:33:42 [24301] DBG:core:MD5StringArray: MD5 calculated: 533cb9e91f4b999cf76861cbb9ed54ed Dec 5 19:33:42 [24301] DBG:core:MD5StringArray: MD5 calculated: bbd8f31c58bc6a3266ec5509a254d55b Dec 5 19:33:42 [24301] DBG:core:init_mod: registering stats for tm Dec 5 19:33:42 [24301] DBG:core:init_mod: register MI for tm Dec 5 19:33:42 [24301] DBG:core:init_mod: initializing module rr Dec 5 19:33:42 [24301] DBG:rr:mod_init: rr - initializing Dec 5 19:33:42 [24301] DBG:core:init_mod: initializing module maxfwd Dec 5 19:33:42 [24301] INFO:maxfwd:mod_init: initializing... Dec 5 19:33:42 [24301] DBG:core:init_mod: initializing module usrloc Dec 5 19:33:42 [24301] DBG:usrloc:mod_init: initializing Dec 5 19:33:42 [24301] INFO:usrloc:ul_init_locks: locks array size 512 Dec 5 19:33:42 [24301] DBG:core:find_mod_export: <db_bind_api> in module db_dbtext not found Dec 5 19:33:42 [24301] DBG:core:db_bind_mod: using export interface to bind db_dbtext Dec 5 19:33:42 [24301] DBG:core:find_mod_export: <db_use_table> in module db_dbtext not found Dec 5 19:33:42 [24301] DBG:core:find_mod_export: <db_init> in module db_dbtext not found Dec 5 19:33:42 [24301] DBG:core:find_mod_export: <db_close> in module db_dbtext not found Dec 5 19:33:42 [24301] DBG:core:find_mod_export: <db_query> in module db_dbtext not found Dec 5 19:33:42 [24301] DBG:core:find_mod_export: <db_fetch_result> in module db_dbtext not found Dec 5 19:33:42 [24301] DBG:core:find_mod_export: <db_raw_query> in module db_dbtext not found Dec 5 19:33:42 [24301] DBG:core:find_mod_export: <db_free_result> in module db_dbtext not found Dec 5 19:33:42 [24301] DBG:core:find_mod_export: <db_insert> in module db_dbtext not found Dec 5 19:33:42 [24301] DBG:core:find_mod_export: <db_delete> in module db_dbtext not found Dec 5 19:33:42 [24301] DBG:core:find_mod_export: <db_update> in module db_dbtext not found Dec 5 19:33:42 [24301] DBG:core:find_mod_export: <db_replace> in module db_dbtext not found Dec 5 19:33:42 [24301] DBG:core:find_mod_export: <db_last_inserted_id> in module db_dbtext not found Dec 5 19:33:42 [24301] DBG:core:find_mod_export: <db_insert_update> in module db_dbtext not found Dec 5 19:33:42 [24301] ERROR:core:db_check_api: module db_dbtext does not export db_use_table function Dec 5 19:33:42 [24301] ERROR:usrloc:mod_init: failed to bind database module Dec 5 19:33:42 [24301] ERROR:core:init_mod: failed to initialize module usrloc Dec 5 19:33:42 [24301] ERROR:core:main: error while initializing modules Dec 5 19:33:42 [24301] DBG:xlog:destroy: destroy module... Dec 5 19:33:42 [24301] DBG:tm:tm_shutdown: tm_shutdown : start Dec 5 19:33:42 [24301] DBG:tm:unlink_timer_lists: emptying DELETE list Dec 5 19:33:42 [24301] DBG:tm:tm_shutdown: emptying hash table Dec 5 19:33:42 [24301] DBG:tm:tm_shutdown: releasing timers Dec 5 19:33:42 [24301] DBG:tm:tm_shutdown: removing semaphores Dec 5 19:33:42 [24301] DBG:tm:tm_shutdown: destroying callback lists Dec 5 19:33:42 [24301] DBG:tm:tm_shutdown: tm_shutdown : done Dec 5 19:33:42 [24301] DBG:db_text:destroy: destroy ... Dec 5 19:33:42 [24301] DBG:core:shm_mem_destroy: Dec 5 19:33:42 [24301] DBG:core:shm_mem_destroy: destroying the shared memory lock --------------------------------------------------------------------------------------------------------------------------------------------------------------------- The kamailio.cfg is as given below: ####### Global Parameters ######### debug=3 log_stderror=no log_facility=LOG_LOCAL0 fork=yes children=4 /* uncomment the following lines to enable debugging */ debug=6 fork=no log_stderror=yes /* uncomment the next line to disable TCP (default on) */ #disable_tcp=yes /* uncomment the next line to enable the auto temporary blacklisting of not available destinations (default disabled) */ #disable_dns_blacklist=no /* uncomment the next line to enable IPv6 lookup after IPv4 dns lookup failures (default disabled) */ #dns_try_ipv6=yes /* uncomment the next line to disable the auto discovery of local aliases based on revers DNS on IPs (default on) */ #auto_aliases=no /* uncomment the following lines to enable TLS support (default off) */ #disable_tls = no #listen = tls:your_IP:5061 #tls_verify_server = 1 #tls_verify_client = 1 #tls_require_client_certificate = 0 #tls_method = TLSv1 #tls_certificate = "//etc/kamailio/tls/user/user-cert.pem" #tls_private_key = "//etc/kamailio/tls/user/user-privkey.pem" #tls_ca_list = "//etc/kamailio/tls/user/user-calist.pem" port=5060 /* uncomment and configure the following line if you want Kamailio to bind on a specific interface/port/proto (default bind on all available) */ #listen=udp:192.168.1.2:5060 ####### Modules Section ######## #set module path mpath="//lib/kamailio/modules/" /* uncomment next line for MySQL DB support */ #loadmodule "db_mysql.so" loadmodule "db_text.so" loadmodule "sl.so" loadmodule "tm.so" loadmodule "rr.so" loadmodule "maxfwd.so" loadmodule "usrloc.so" loadmodule "registrar.so" loadmodule "textops.so" loadmodule "mi_fifo.so" loadmodule "uri_db.so" loadmodule "uri.so" loadmodule "xlog.so" loadmodule "acc.so" /* uncomment next lines for MySQL based authentication support NOTE: a DB (like db_mysql) module must be also loaded */ loadmodule "auth.so" loadmodule "auth_db.so" /* uncomment next line for aliases support NOTE: a DB (like db_mysql) module must be also loaded */ #loadmodule "alias_db.so" /* uncomment next line for multi-domain support NOTE: a DB (like db_mysql) module must be also loaded NOTE: be sure and enable multi-domain support in all used modules (see "multi-module params" section ) */ #loadmodule "domain.so" /* uncomment the next two lines for presence server support NOTE: a DB (like db_mysql) module must be also loaded */ #loadmodule "presence.so" #loadmodule "presence_xml.so" # ----------------- setting module-specific parameters --------------- modparam("db_text", "db_mode", 0) # ----- mi_fifo params ----- modparam("mi_fifo", "fifo_name", "/tmp/kamailio_fifo") # ----- rr params ----- # add value to ;lr param to cope with most of the UAs modparam("rr", "enable_full_lr", 1) # do not append from tag to the RR (no need for this script) modparam("rr", "append_fromtag", 0) # ----- rr params ----- modparam("registrar", "method_filtering", 1) /* uncomment the next line to disable parallel forking via location */ # modparam("registrar", "append_branches", 0) /* uncomment the next line not to allow more than 10 contacts per AOR */ #modparam("registrar", "max_contacts", 10) # ----- uri_db params ----- /* by default we disable the DB support in the module as we do not need it in this configuration */ modparam("uri_db", "use_uri_table", 0) modparam("uri_db", "db_url", "") # ----- acc params ----- /* what sepcial events should be accounted ? */ modparam("acc", "early_media", 1) modparam("acc", "report_ack", 1) modparam("acc", "report_cancels", 1) /* by default ww do not adjust the direct of the sequential requests. if you enable this parameter, be sure the enable "append_fromtag" in "rr" module */ modparam("acc", "detect_direction", 0) /* account triggers (flags) */ modparam("acc", "failed_transaction_flag", 3) modparam("acc", "log_flag", 1) modparam("acc", "log_missed_flag", 2) /* uncomment the following lines to enable DB accounting also */ modparam("acc", "db_flag", 1) modparam("acc", "db_missed_flag", 2) # ----- usrloc params ----- modparam("usrloc", "db_mode", 0) /* uncomment the following lines if you want to enable DB persistency for location entries */ modparam("usrloc", "db_mode", 2) modparam("usrloc", "db_url", "dbtext:///usr/local/etc/kamailio/dbtext") # ----- auth_db params ----- /* uncomment the following lines if you want to enable the DB based authentication */ modparam("auth_db", "calculate_ha1", yes) modparam("auth_db", "password_column", "password") modparam("auth_db", "db_url", "dbtext:///usr/local/etc/kamailio/dbtext") #modparam("auth_db", "load_credentials", "") # ----- alias_db params ----- /* uncomment the following lines if you want to enable the DB based aliases */ #modparam("alias_db", "db_url", # "mysql://openser:openserrw@localhost/openser") # ----- domain params ----- /* uncomment the following lines to enable multi-domain detection support */ #modparam("domain", "db_url", # "mysql://openser:openserrw@localhost/openser") #modparam("domain", "db_mode", 1) # Use caching # ----- multi-module params ----- /* uncomment the following line if you want to enable multi-domain support in the modules (dafault off) */ #modparam("alias_db|auth_db|usrloc|uri_db", "use_domain", 1) # ----- presence params ----- /* uncomment the following lines if you want to enable presence */ #modparam("presence|presence_xml", "db_url", # "mysql://openser:openserrw@localhost/openser") #modparam("presence_xml", "force_active", 1) #modparam("presence", "server_address", "sip:192.168.1.2:5060") ####### Routing Logic ######## # main request routing logic route{ if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; } if (has_totag()) { # sequential request withing a dialog should # take the path determined by record-routing if (loose_route()) { if (is_method("BYE")) { setflag(1); # do accounting ... setflag(3); # ... even if the transaction fails } route(1); } else { /* uncomment the following lines if you want to enable presence */ ##if (is_method("SUBSCRIBE") && $rd == "your.server.ip.address") { ## # in-dialog subscribe requests ## route(2); ## exit; ##} if ( is_method("ACK") ) { if ( t_check_trans() ) { # non loose-route, but stateful ACK; must be an ACK after a 487 or e.g. 404 from upstream server t_relay(); exit; } else { # ACK without matching transaction ... ignore and discard.\n"); exit; } } sl_send_reply("404","Not here"); } exit; } #initial requests # CANCEL processing if (is_method("CANCEL")) { if (t_check_trans()) t_relay(); exit; } t_check_trans(); # authenticate if from local subscriber (uncomment to enable auth) if (!(method=="REGISTER") && from_uri==myself) { if (!proxy_authorize("192.168.20.35", "subscriber")) { proxy_challenge("192.168.20.35", "0"); exit; } if (!check_from()) { sl_send_reply("403","Forbidden auth ID"); exit; } consume_credentials(); # caller authenticated } # record routing if (!is_method("REGISTER|MESSAGE")) record_route(); # account only INVITEs if (is_method("INVITE")) { setflag(1); # do accounting } if (!uri==myself) /* replace with following line if multi-domain support is used */ ##if (!is_uri_host_local()) { append_hf("P-hint: outbound\r\n"); # if you have some interdomain connections via TLS ##if($rd=="tls_domain1.net") { ## t_relay("tls:domain1.net"); ## exit; ##} else if($rd=="tls_domain2.net") { ## t_relay("tls:domain2.net"); ## exit; ##} route(1); } # requests for my domain /* uncomment this if you want to enable presence server and comment the next 'if' block NOTE: uncomment also the definition of route[2] from below */ ##if( is_method("PUBLISH|SUBSCRIBE")) ## route(2); if (is_method("PUBLISH")) { sl_send_reply("503", "Service Unavailable"); exit; } if (is_method("REGISTER")) { # authenticate the REGISTER requests (uncomment to enable auth) if (!www_authorize("192.168.20.35", "subscriber")) { www_challenge("192.168.20.35", "0"); exit; } if (!check_to()) { sl_send_reply("403","Forbidden auth ID"); exit; } if (!save("location")) sl_reply_error(); exit; } if ($rU==NULL) { # request with no Username in RURI sl_send_reply("484","Address Incomplete"); exit; } # apply DB based aliases (uncomment to enable) ##alias_db_lookup("dbaliases"); if (!lookup("location")) { switch ($retcode) { case -1: case -3: t_newtran(); t_reply("404", "Not Found"); exit; case -2: sl_send_reply("405", "Method Not Allowed"); exit; } } # when routing via usrloc, log the missed calls also setflag(2); route(1); } route[1] { # for INVITEs enable some additional helper routes if (is_method("INVITE")) { t_on_branch("2"); t_on_reply("2"); t_on_failure("1"); } if (!t_relay()) { sl_reply_error(); }; exit; } # Presence route /* uncomment the whole following route for enabling presence NOTE: do not forget to enable the call of this route from the main route */ ##route[2] ##{ ## if (!t_newtran()) ## { ## sl_reply_error(); ## exit; ## }; ## ## if(is_method("PUBLISH")) ## { ## handle_publish(); ## t_release(); ## } ## else ## if( is_method("SUBSCRIBE")) ## { ## handle_subscribe(); ## t_release(); ## } ## ## exit; ##} branch_route[2] { xlog("new branch at $ru\n"); } onreply_route[2] { xlog("incoming reply\n"); } failure_route[1] { if (t_was_cancelled()) { exit; } # uncomment the following lines if you want to block client # redirect based on 3xx replies. ##if (t_check_status("3[0-9][0-9]")) { ##t_reply("404","Not found"); ## exit; ##} # uncomment the following lines if you want to redirect the failed # calls to a different new destination ##if (t_check_status("486|408")) { ## sethostport("192.168.2.100:5060"); ## append_branch(); ## # do not set the missed call flag again ## t_relay(); ##} } ------------------------------------------------------------------------------------------------------------------------------------ Any suggestion will be very helpful. Thanks in advance. Dhaval

2 1

[Kamailio-Users] Port of kamailio to OpenBSD
by Don Jackson 05 Dec '08

05 Dec '08

I have motivated the creation of a port of kamailio to OpenBSD, the port creates binary packages, which can then be added via the pkg_add command. I could definitely use input and testing of this port from the kamailio community, if you are interested in running kamailio on OpenBSD, I could use your help! We also needed to create a port of radiusclient to support kamailio. Both ports are attached to the messages appended below. Don Begin forwarded message: > From: Don Jackson <don.jackson(a)gmail.com> > Date: November 18, 2008 11:16:22 AM PST > To: ports(a)openbsd.org > Subject: NEW: telephony/kamailio-1.4.2 (kamailio used to be called > OpenSER) > > > Tested on 4.4/amd64, definitely interested in more testing > > $ cat DESCR-main > > KAMAILIO (OpenSER) is a mature and flexible open source SIP server > (RFC3261). > It can be used on systems with limitted resources as well as on > carrier grade > servers, scaling to up to thousands call setups per second. It is > written in > pure C for Unix/Linux-like systems with architecture specific > optimizations to > offer high performances. It is customizable, being able to feature > as fast load > balancer; SIP server flavours: registrar, location server, proxy > server, > redirect server; gateway to SMS/XMPP; or advanced VoIP application > server. > > Begin forwarded message: > From: Don Jackson <don.jackson(a)gmail.com> > Date: November 18, 2008 11:11:53 AM PST > To: ports(a)openbsd.org > Subject: NEW: net/radiusclient-ng-0.5.6 > > > This port is needed for the kamailio/openser port (see subsequent > email) > > Tested on 4.4/amd64, definitely interested in more testing. > > $ cat pkg/DESCR > > Purpose of this project is to build portable, easy-to-use and standard > compliant library suitable for developing free and commercial software > that need support for a RADIUS protocol (RFCs 2138 and 2139). > > > >

2 3

[Kamailio-Users] reply_route is not called though a response is received
by Aurelien Grimaud 05 Dec '08

05 Dec '08

Hi, I am running a rather old version of openser, but since in a production context, I cannot upgrade anytime I want to catch up with newer releases. I searched bugs and googled for my problem without any result. There it is. I have a module with functions beginning with mn_ mn_received handle any incoming request and prints it out. my module has a callback on response which prints out responses. My configuration file is something like // handle register mn_received() ; record_route() ; if ( method=="INVITE") { t_on_failure(ROUTE_INVITE) ; t_on_reply(ROUTE_INVITE) ; } Then the request is t_relayed to destination. The onreply_route[ROUTE_INVITE] prints some output, and fix_contact on 200, ... whatever. Then this happens : - An INVITE is received from A (I see it with mn_received) - INVITE is relayed to destination B - B replies 180, I see the response on my module output and I see my onreply_route[INVITE] statements. - B replies 200, I see the response on my module output, but, I *do not* see my reply_route statements. - A sends ACK for INVITE - ACK is relayed to B 2 minutes later (fr_inv_timer), the failure_route[INVITE] is triggered ! Since I use failure routes to manage serial forking, this means openser forward the initial INVITE to the other destination, though first call was established ! Moreover, first call, which seems ok is CANCELED by the openser (I can see a 200 answer to a cancel from B) Openser did not disarm the fr_inv_timer on "200" answer to INVITE ? Openser did not triggered my onreply_route... Has someone already experienced this ? Has someone a clue where it may come from ? - Sometimes it works ok - Sometimes, 180 is not "seen" and 200 is ok - Sometimes 180 is seen but not 200 - Sometimes neither 180, nor 200 are seen - Headers in 180 and 200 are the same except for content - I'm running openser-1.2.0 (ouch !) I'm stuck ! Could this be related to 2008-05-15 10:59 Bogdan-Andrei Iancu, <bogdan at voice-system dot ro> * [r4191] modules/tm/t_reply.c: backport from trunk (rev #4190): - fixed race condition that may lead to deadlock on the transaction lock. As the reply route (t_on_reply()) stored in transaction may be changed in reply route br the current process or any other process, to avoid race conditions, it is better to make a local copy of the reply route number to be sure it will not be changed. The deadlock can appear as the reply route number is used in several conditions to determine id locking is required. But as this value may be changed (by current or other process), it may lead to multiple lockings with no unlock -> deadlock. NOTE: this might happen only if onreply_avp_mode is turned on. Aurelien

2 2

Re: [Kamailio-Users] Failover from SRV lookups?
by Henning Westerholt 05 Dec '08

05 Dec '08

On Thursday 04 December 2008, Geir O. Jensen wrote: > [..] > However, this sounds like it will only solve the problem every other time, > so some calls will go through quicker than the others. I guess our GW > supplier should've used a better solution for their loadbalancing (for > instance anycast) but that is out of my hands. > > Thanks again for the tip, I'll keep it in mind if/when we upgrade... Hi Geir, one other thing would be to not use the SRV records for loadbalancing. I think the dispatcher module has functionality to query configured servers with an options ping, and disable balancing to failed ones. Or you can use the carrierroute module, which gives you complete control over the routing, you can disable then the failed GW with some external scripts. Cheers, Henning

2 1

[Kamailio-Users] callerid openser
by Ricky Gutierrez 04 Dec '08

04 Dec '08

Hi , is possible to negotiate the callerid for each extension with openser? regards rickygm

2 2

Re: [Kamailio-Users] Thomson ST2030 SIP contact problem
by Samuel Muller 04 Dec '08

04 Dec '08

Hello, I tried all the ways you told : I moved the SIP phone at home, which I don't have any firewall and it does not pass through the entreprise fw. so the SIP phone is directly connected to the proxy. it registers well, no pbm, but the problem stay. Impossible to make a call to the Thomson. INVITE from any SIP phone (hard or soft, I tried with a Linksys, then a SJ Phone) through Kamailio is not going to the Thomson. All the others SIP stuff are working (Linksys to SJ Phone, ...). I tried many configuration changes into the Thomson ST2030, unsuccessfully. I mean it's not a NAT problem ... Here you are the SIP messages in the kamailio debug from SJ Phone (0123451011) to the f***in' Thomson (0123451014) : Dec 1 20:49:36 kamailio[29592]: -> incoming SIP buffer message: INVITE sip:0123451014@sip.720.fr <sip%3A0123451014(a)sip.720.fr> SIP/2.0 Via: SIP/2.0/UDP 192.168.1.3 ;rport;branch=z9hG4bKc0a801030000004549343fcf39c16ac5000000f0 Content-Length: 264 Contact: <sip:0123451011@192.168.1.3:5060> Call-ID: 2E029B5E-1DD2-11B2-A585-993A960A9D75(a)192.168.1.3 Content-Type: application/sdp CSeq: 2 INVITE From: "sambook"<sip:0123451011@sip.720.fr <sip%3A0123451011(a)sip.720.fr> >;tag=409529589751851917 Max-Forwards: 70 To: <sip:0123451014@sip.720.fr <sip%3A0123451014(a)sip.720.fr>> User-Agent: SJphone/1.60.299a/L (SJ Labs) Proxy-Authorization: Digest username="0123451011",realm="sip.720.fr", nonce="493440fb0000001024641d0bca47789c4c6f68d81262f201",uri=" sip:0123451014@sip.720.fr <sip%3A0123451014(a)sip.720.fr>", response="b8df3912d21ddd8aca40c0bf254bbdcf",cnonce="40952964931016109891",qop="auth",nc="00000001" v=0 o=- 3437149775 3437149775 IN IP4 192.168.1.3 s=SJphone c=IN IP4 192.168.1.3 t=0 0 a=direction:active m=audio 49168 RTP/AVP 0 8 3 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:3 GSM/8000 Dec 1 20:49:36 kamailio[29592]: -> outgoing SIP buffer message: INVITE sip:0123451014@sip.720.fr <sip%3A0123451014(a)sip.720.fr> SIP/2.0 Via: SIP/2.0/UDP 192.168.1.3 ;rport;branch=z9hG4bKc0a801030000004549343fcf39c16ac5000000f0 Content-Length: 264 Contact: <sip:0123451011@192.168.1.3:5060> Call-ID: 2E029B5E-1DD2-11B2-A585-993A960A9D75(a)192.168.1.3 Content-Type: application/sdp CSeq: 2 INVITE From: "sambook"<sip:0123451011@sip.720.fr <sip%3A0123451011(a)sip.720.fr> >;tag=409529589751851917 Max-Forwards: 69 To: <sip:0123451014@sip.720.fr <sip%3A0123451014(a)sip.720.fr>> User-Agent: SJphone/1.60.299a/L (SJ Labs) Proxy-Authorization: Digest username="0123451011",realm="sip.720.fr", nonce="493440fb0000001024641d0bca47789c4c6f68d81262f201",uri=" sip:0123451014@sip.720.fr <sip%3A0123451014(a)sip.720.fr>", response="b8df3912d21ddd8aca40c0bf254bbdcf",cnonce="40952964931016109891",qop="auth",nc="00000001" v=0 o=- 3437149775 3437149775 IN IP4 192.168.1.3 s=SJphone c=IN IP4 192.168.1.3 t=0 0 a=direction:active m=audio 49168 RTP/AVP 0 8 3 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:3 GSM/8000 In the attached file, the full kamailio debug level 9. It seems that nothing is coming to the Thomson (I don't have any hub where I can sniff the frames). "The truth is out there" ... :/ .desperate house Sam. On Mon, Dec 1, 2008 at 1:44 PM, Samuel Muller <sml(a)720.fr> wrote: > many thanks Klaus, > > I'll check tonight at home, and will reply to you after. > > sincerely, thanks ! > > .Sam. > > > > > On Mon, Dec 1, 2008 at 1:28 PM, Klaus Darilion < > klaus.mailinglists(a)pernau.at> wrote: > >> Hi Samuel! >> >> The INVITE sent from Kamailio to Thomson phone does not trigger any >> response. There are various possible reasons: >> >> 1. INVITE is ignored by Thomson phone >> 2. INVITE does not make it thorugh to the Thomson phone >> 2.1 either sent to the wrong port >> 2.2 or the NAT binding time out, thus NAT does not forward correctly >> >> Thus, verify if the INVITE is received by the NAT device and forwarded to >> the Thomson phone (e.g. putting a hub between the NAT router and the phone). >> REGISTER with the Thomson phone and then immediately after call it >> (linksys->thomson) - this should work as the binding should be alive just >> after the registration. >> >> The problem could also be caused by a buggy NAT router or VPN client or >> firewall ALGs. >> >> To further debug this issue you could also try the Thomson phone with >> another VoIP service (e.g. iptel.org or ekiga.net) or try the Thomson >> phone from another access (e.g. try it at home bypassing your company >> FW/NAT). >> >> You could also try to avoid port 5060, e.g. Put the proxy on port 5678 and >> also use other ports locally for the SIP clients. SIP ALGs (application >> level gateways) usually are triggered by port 5060. >> >> regards >> klaus >> >> >> Samuel Muller schrieb: >> >>> >>> >>> On Mon, Dec 1, 2008 at 12:24 PM, Klaus Darilion < >>> klaus.mailinglists(a)pernau.at <mailto:klaus.mailinglists@pernau.at>> >>> wrote: >>> >>> >>> >>> Samuel Muller schrieb: >>> >>> Hey Klaus, >>> >>> first, some answers : >>> >>> -> when a thomson is the callee, there's no ringing even if >>> indicated into the SIP message. >>> -> when a thomson is the caller, no problem, there's a ring, and >>> the call is ok with audio. >>> >>> >>> Please be a bit more specific: What does "no ring" mean? >>> No "180 ringing" response from callee to caller? >>> "180 ringing" response but no "ring-back" at the caller's client? >>> >>> >>> oups, sorry, I mean : SIP messages are ok, there is all the sig process. >>> >>> the architecture is : >>> linksys + thomson -> cisco 827 -> SDSL -> our backbone which have a >>> firewall for VPN (so NAT and NAPT are applied here), then the kamailio with >>> a public ip. >>> >>> you have the 100 trying, 180 ringing in the SIP message, but there's no >>> ring-back tone for the callee. >>> >>> in the attached file : >>> linksys to linksys, where all the call process is ok (sip + rtp) >>> thomson to linksys, idem >>> linksys to thomson, sip ok but rtp apparently not. >>> I forgot the firewall for the vpn, rtp proxying is required, sorry - so >>> yes rtp proxy must be used. >>> >>> regards, >>> >>> .Sam. >>> >>>

2 2

Re: [Kamailio-Users] Kamailio 1.4.1 fails at startup
by Henning Westerholt 04 Dec '08

04 Dec '08

On Thursday 04 December 2008, Arturo Díaz Almagro wrote: > Hi Henning, > > Forget the last mail. This is the configuration and the output log. I got a > segmentation fault in the pdt module: > [..] > Dec 4 13:28:37 mediaGW kamailio[9082]: DBG:db_text:dbt_load_file: > column[0] is INT! > > This error is gotten with kamailio 1.4.1 and 1.4.2. If I comment out the > modparam lines configuring pdt module kamailio starts up correctly. Hi Arturo, do you get a core dump from the segmention fault? If not, please enable the core dumping (e.g. with ulimit -c unlimited), and send me the backtrace when you examine the dump with gdb. As alternative you could also send me the DB contents that leads to the crash with private mail. Cheers, Henning

1 0

Re: [Kamailio-Users] lost path
by Daniel-Constantin Mierla 04 Dec '08

04 Dec '08

Hello, please post such questions to users mailing lists (cc-ed). Cheers, Daniel On 12/04/08 01:18, Waseem Besada wrote: > Hi > > I highly appreciate your help to solve the error I get when I try to > create a database. It seems that path to standard-create.sql is not > set probably and I'm lost how this can be fixed. > > Thank you in advance, > /Waseem > > linux-0g00:/usr/local/sbin # ./kamdbctl create > MySQL password for root: > INFO: test server charset > INFO: creating database openser ... > /usr/local/lib64/kamailio/kamctl/kamdbctl.mysql: line 155: > ./mysql/standard-create.sql: No such file or directory > ERROR: Creating core tables failed! >

1 0

[Kamailio-Users] Kamailio 1.4.1 fails at startup
by Arturo Díaz Almagro 03 Dec '08

03 Dec '08

Hello all, I am defining a little script for Kamailio working as a simple forwarder (doing some simple tasks sometimes). I have to use an static database with few rows of PDT data so I decided to use a text database via db_text module. The scripts seems to ok because I do not get any error message from start up logging but kamailio processes are not there!! Moreover, I am not making use of the functions in the script, only initialization!! I am using kamailio-1.4.1-notls and these are the script lines defining the initialization of those modules. Thanks a lot. ####### Global Parameters ######### debug=3 log_stderror=no fork=yes children=7 #KAMAILIO_CHILDREN /* uncomment the next line to disable TCP (default on) */ disable_tcp=yes /* uncomment the next line to enable the auto temporary blacklisting of not available destinations (default disabled) */ #disable_dns_blacklist=no /* uncomment the next line to enable IPv6 lookup after IPv4 dns lookup failures (default disabled) */ #dns_try_ipv6=yes /* uncomment the next line to disable the auto discovery of local aliases based on revers DNS on IPs (default on) */ #auto_aliases=no /* uncomment and configure the following line if you want Kamailio to bind on a specific interface/port/proto (default bind on all available) */ listen=udp:172.16.10.1:5060#KAMAILIO_PROTO:KAMAILIO_IP:KAMAILIO_PORT port=5060 #KAMAILIO_PORT /* domain alias for the host */ alias=domain1.com #KAMAILIO_DOMAIN # global domain alias=domain2.com ####### Modules Section ######## #set module path mpath="//lib/kamailio/modules/" loadmodule "db_text.so" loadmodule "sl.so" loadmodule "tm.so" loadmodule "rr.so" loadmodule "maxfwd.so" loadmodule "textops.so" loadmodule "mi_fifo.so" loadmodule "uri.so" loadmodule "xlog.so" loadmodule "path.so" loadmodule "pdt.so" loadmodule "avpops.so" # ----------------- setting module-specific parameters --------------- modparam("pdt|avpops", "db_url", "text:///tmp/kamailio_db") # ----- mi_fifo params ----- modparam("mi_fifo", "fifo_name", "/tmp/kamailio_fifo") # ----- rr params ----- # add value to ;lr param to cope with most of the UAs modparam("rr", "enable_full_lr", 1) # do not append from tag to the RR (no need for this script) #modparam("rr", "append_fromtag", 0) # ----- path params ----- modparam("path", "use_received", 0) # ----- dbtext ----- modparam("db_text", "db_mode", 0) # ----- pdt params ----- modparam("pdt", "db_table", "pdt") modparam("pdt", "sdomain_column", "sdomain") modparam("pdt", "prefix_column", "prefix") modparam("pdt", "domain_column", "domain") ####### Routing Logic ######## [..] -- Arturo Díaz

2 2

[Kamailio-Users] How are computed $Tf and $Ts?
by Iñaki Baz Castillo 03 Dec '08

03 Dec '08

Hi, it doesn't make sense: xlog("L_INFO","--- time pre http: $Tf - $Ts\n"); http_query("/test1.html", "r_uri=$(ru{s.escape.param})&f_uri=$(fu{s.escape.param})", "$var(result)"); xlog("L_INFO","--- time post http: $Tf - $Ts\n"); I always get: --- time pre http: Mon Nov 24 14:37:25 2008 - 1227533845 --- time post http: Mon Nov 24 14:37:25 2008 - 1227533845 Of course it's just impossible that the http query takes 0.000 seconds. I could use 'benchmark' module fot this stuf, but I wonder why $Tf returns the same value in any place of the script. Maybe it is just computed at the script start for each message? Thanks. -- Iñaki Baz Castillo

2 4

Re: [Serusers] How can I keep SER from changing reply Response Code from 503 to 500?
by Frank Durda IV 03 Dec '08

03 Dec '08

Jeroen van Bemmel wrote: > Frank, > > RFC3261 specifically specifies that proxies should convert response code > 503 into 500: > > A proxy which receives a 503 (Service Unavailable) response > SHOULD NOT forward it upstream unless it can determine that any > subsequent requests it might proxy will also generate a 503. > In other words, forwarding a 503 means that the proxy knows it > cannot service any requests, not just the one for the Request- > URI in the request which generated the 503. If the only > response that was received is a 503, the proxy SHOULD generate > a 500 response and forward that upstream. > > So SER is behaving in accordance with the standard. There might be a > configuration option to turn this off? Well, yes and no. Thanks for pointing out this item in the RFC which I missed, but if the RFC action is honored, then SER should have emitted "500 Server Internal Error" which is in the RFC, and not the hybrid and made-up "500 Service Unavailable", which is not in the RFC. So, I think SER is wrong at least on that point. (Personally I think SIP desperately needs at least 20 additional defined Response Codes so we can all quit using the existing not-entirely-inappropriate values to cover real-life situations, but right now the book says that's all the codes that we've all got to work with. When you see a dozen SS7 release codes all map to the same SIP Response Codes, you don't have nearly enough SIP Response Codes, but I digress.) That said, our SER server knows the given condition sent from a paired PSTN switch is permanent, eg the SIP caller can't call this number via our network now, tomorrow or next week because of who you they or whom their provider is (or what they failed to buy), so in this situation returning 503 all the way out of our network is correct behavior (as stated in the RFC), and doing so allows the upstream entity to click over to the next preferred carrier that might reach that destination. We have found that many SIP providers simply blindly lob all calls at the cheapest carrier and if a given call bounces, repeat that action with the next-cheapest carrier, and the next until they finally resort to a Tandem that will take anything, but will also be the most expensive way to route the call. Nearly all require us to send them back a 503 (a few want us to send 502 back instead) to say back to them "not via here, try next door". Deplorable and this method certainly causes slow call set-up times, but that is what quite a few of these outfits are doing. So, our SER must send them back a 503 and not a 500 in this situation. If I explicitly state one in a reply rule, will that override this default behavior, or will some deeper part of SER veto even a sl_reply("503", "Service Unavailable"); added to the onreply_route? If so, where is this piece of source code, so that I may break this well-intended but undesired behavior?

5 8

[Kamailio-Users] important: pseudo-variables moved to pv module
by Daniel-Constantin Mierla 03 Dec '08

03 Dec '08

Hello, please note that pseudo-variables implemented in core for kamailio/openser versions <= 1.4.x are now moved in pv module. This is part of cleaning up the core, in order to keep it slimmer and less exposed to bugs. There are modules and use cases that need no PVs, therefore no need of keeping the implementation of about 100 PV in core. Now the core includes only an API that allows to: - register PVs from modules - parse PV names in config script, evaluate PVs, assign values to PVs $shv() - shared variables, and $time() - broken down time, were moved from cfgutils module to pv module ($shv() depends on $var()). To summarize, if you need $ru, $avp(...), $var(...), a.s.o. in your config file you have to load pv module from now on with devel version and upcoming stable releases. Two new pseudo-variables were introduced with this occasion, $TS and $TF, see more: http://www.kamailio.org/dokuwiki/doku.php/pseudovariables:devel#string_form… http://www.kamailio.org/dokuwiki/doku.php/pseudovariables:devel#unix_time_s… Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

1 0

[Kamailio-Users] how to use 2 mysql servers?
by BERGANZ François 03 Dec '08

03 Dec '08

Hello, I need to know how to use 2 mysql servers, if my first server go down Have you an idea? thankyopu Cordialement, BERGANZ François P Pensez à l'Environnement, n'imprimez ce mail que si nécessaire.

10 18

[Kamailio-Users] 403 Forbidden to SUBSCRIBE for reg-event package
by skumar453＠gmail.com 03 Dec '08

03 Dec '08

Hi, I am getting "403 Forbidden to SUBSCRIBE" error message. below is the scenario: 1. SCSCF is sending third party register request (with reg event) to AS. 2. AS is sending back 200 OK 3. AS is sending SUBSCRIBE (with reg event) to SCSCF. 4. scscf is sending back "403 - Forbidden to SUBSCRIBE" error message to AS. my SIP message is inline with the specification 24.141 (section: A.7. PNA subscription for the reg-event package) also. Here is my SIP message: ----------------------- SUBSCRIBE sip:alice@mydomain.com SIP/2.0 Via: SIP/2.0/UDP 172.18.2.92:5065;branch=z9hG4bK374b.eee261c1.0 To: sip:alice@mydomain.com From: sip:172.18.2.92:5065;tag=933e5c49d48198cc3b1dfd0b30660d07-2f8d CSeq: 10 SUBSCRIBE Call-ID: 2d0f7fbf-1185(a)172.18.2.92 Content-Length: 0 User-Agent: OpenSIPS (1.4.0-notls (i386/linux)) Max-Forwards: 70 Event: reg Contact: <sip:172.18.2.92:5065> P-Asserted-Identity: <sip:172.18.2.92:5065> Expires: 600000 Can anybody help me resolving this? Regards, suresh

2 1

[Kamailio-Users] load_credentials() in auth_db.
by Alex Balashov 03 Dec '08

03 Dec '08

Are there any plans to allow loading of credentials into userspace variables ($var(column)) in addition to AVPs? -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599

2 1

Re: [Serusers] Registering port instead of contact field port
by Iñaki Baz Castillo 02 Dec '08

02 Dec '08

El Jueves, 27 de Noviembre de 2008, Daniel Serrano escribió: > Dear all, > > I am using SER as IM server and I found that the SER use the contact > field to storage the user's location in the memory for future requests. > I noted this using the command "serctl alias show" and checking some > traces. > Since I'm using a NAT scenario I'd like to use the UDP port that my > SER server receives during the registration instead of the contact > field port to reach the users after their registration. Is there any > way to do this? "rport" does it, but the client must indicate support of "rport" by adding ";rport" parameter to its Via header. Anyway, *SER can force it by using "force_rport()". -- Iñaki Baz Castillo

3 5

[Kamailio-Users] PDT module - multiple prefix single domain
by Matteo Piazza 02 Dec '08

02 Dec '08

Hi all, I notice a thing about PDT module. If you try to put in the table two entry with the same destination domain at the load of the parameter is reported an error of duplication: Nov 28 09:32:23 [5169] ERROR:pdt:pdt_load_db: sdomain [*]: prefix [04610202] or domain <tnn.multivoce.tnnet.it> duplicated entry of the table id | sdomain | prefix | domain ----+---------+----------+-------------------------- 1 | * | * | intercom.tnnet.it 4 | * | 04610200 | tsm.multivoce.tnnet.it 2 | * | 04610201 | tnn.multivoce.tnnet.it 3 | * | 04610202 | tnn.multivoce.tnnet.it Is this mean that the prefix must be only one for a single domain. This is a limition where I have a single domain that manage multiple prefix not consecutive. Did I understand right? Matteo -- ==================================== Matteo Piazza Trentino Network s.r.l. a Socio Unico matteo.piazza(a)trentinonetwork.it Via Gilli, 2 - 38100 TRENTO Tel (+39) 0461.020224 ====================================

3 6

[Kamailio-Users] Meeting at 25C3 in Berlin
by Henning Westerholt 01 Dec '08

01 Dec '08

Hello all, i'll be present this year at the 25th Chaos Communication Congress in Berlin [1], December 27th to 30th, 2008. So if some people here also participate in this event, and want to meet for some hacking sessions and discussions around the Kamailio/ sip-router project please drop me a personal mail. Regards, Henning [1] http://events.ccc.de/congress/2008/

1 0

Re: [Kamailio-Users] Thomson ST2030 SIP contact problem
by Samuel Muller 01 Dec '08

01 Dec '08

On Mon, Dec 1, 2008 at 12:24 PM, Klaus Darilion < klaus.mailinglists(a)pernau.at> wrote: > > > Samuel Muller schrieb: > >> Hey Klaus, >> >> first, some answers : >> >> -> when a thomson is the callee, there's no ringing even if indicated >> into the SIP message. >> -> when a thomson is the caller, no problem, there's a ring, and the call >> is ok with audio. >> > > Please be a bit more specific: What does "no ring" mean? > No "180 ringing" response from callee to caller? > "180 ringing" response but no "ring-back" at the caller's client? > oups, sorry, I mean : SIP messages are ok, there is all the sig process. the architecture is : linksys + thomson -> cisco 827 -> SDSL -> our backbone which have a firewall for VPN (so NAT and NAPT are applied here), then the kamailio with a public ip. you have the 100 trying, 180 ringing in the SIP message, but there's no ring-back tone for the callee. in the attached file : linksys to linksys, where all the call process is ok (sip + rtp) thomson to linksys, idem linksys to thomson, sip ok but rtp apparently not. I forgot the firewall for the vpn, rtp proxying is required, sorry - so yes rtp proxy must be used. regards, .Sam. > > -> the SIP mesages are the same in the 2 cases. >> >> incoming invite are exactly the same (but the source IP, and the >> "user=phone" parameter, for sure). >> outgoing invite, in the 2 cases, replaces the source IP on the "c" line >> into the SDP by the RTP proxy IP (but at the end, it indicates >> a=nortpproxy:yes >> > > a=nortpproxy:yes is fine. This line will signal to upstream proxies that an > RTP proxy was already activated and there is no need to activate further RTP > proxies. > > > Please post a complete ngrep trace (INVITE.....BYE) for the sucessfull and > for the unsuccessful call. > > > Did I force 2 times the RTP proxy, or is there a >> > > no > > fix_nated_contact/fix_nated_register pbm ? >> > > For REGISTER handling you use fix_nated_register. For all other cases you > use fix_nated_contact. > > > BTW: What do you mean by "there's no RTP proxying" in the "not ok" case? > > regards > klaus > > >> really strange, I can send to you the kamailio debugs if you need it >> >> in advance many thanks, >> >> .Sam. >> >> >> >> >> On Mon, Dec 1, 2008 at 11:50 AM, Klaus Darilion < >> klaus.mailinglists(a)pernau.at <mailto:klaus.mailinglists@pernau.at>> >> wrote: >> >> Hi Samuel! >> >> What exactly is the problem when "not ok". >> is signaling fine? >> what is the audio problem (one way audio? no audio at all?) >> >> compare the SDP of the incoming INVITE with the outgoing INVITE. If >> you use rtpproxy, the IP address in the c line should be changed. >> >> >> regards >> klaus >> >> Samuel Muller schrieb: >> >> Hello, >> >> >> ok, I tested this in the same LAN : >> >> Thomson st2030 -> Linksys spa941 : ok >> Linksys -> Thomson : not ok >> Linksys -> another working Linksys : ok >> Thomson -> another Thomson : not ok >> >> Indeed there's no RTP proxying. >> I check all the SIP messages below, the only differences I saw >> are : "user=phone" and the rtpmap. >> concerning NAT there are behind the same router, the location >> saved is fine ? >> >> in the kamailio log, the routing logic is the same. >> registration of all sip phones are ok, proxy auth too. >> the Thomsons can't find any other sip phones ... >> >> here are all the invites (got with ngrep) : >> >> >> *** Here you have the INVITE message in the case Linksys => >> Linksys (call ok) >> >> U 2008/12/01 10:34:09.950709 77.246.81.162:25722 >> <http://77.246.81.162:25722> <http://77.246.81.162:25722> -> >> 77.246.81.132:5060 <http://77.246.81.132:5060> >> <http://77.246.81.132:5060> >> INVITE sip:0123451010@sip.720.fr <sip%3A0123451010(a)sip.720.fr> >> <mailto:sip%3A0123451010@sip.720.fr<sip%253A0123451010(a)sip.720.fr> >> > >> <mailto:sip%3A0123451010@sip.720.fr<sip%253A0123451010(a)sip.720.fr> >> <mailto:sip%253A0123451010@sip.720.fr<sip%25253A0123451010(a)sip.720.fr>>> >> SIP/2.0. >> >> Via: SIP/2.0/UDP 192.168.0.120:5060;branch=z9hG4bK-bdbd130c. >> From: "linksys1" <sip:0123451005@sip.720.fr<sip%3A0123451005(a)sip.720.fr> >> <mailto:sip%3A0123451005@sip.720.fr<sip%253A0123451005(a)sip.720.fr> >> > >> <mailto:sip%3A0123451005@sip.720.fr<sip%253A0123451005(a)sip.720.fr> >> <mailto:sip%253A0123451005@sip.720.fr<sip%25253A0123451005(a)sip.720.fr> >> >>>;tag=6fc94d28edd8dcaao0. >> To: "linksys2" <sip:0123451010@sip.720.fr<sip%3A0123451010(a)sip.720.fr> >> <mailto:sip%3A0123451010@sip.720.fr<sip%253A0123451010(a)sip.720.fr> >> > >> <mailto:sip%3A0123451010@sip.720.fr<sip%253A0123451010(a)sip.720.fr> >> <mailto:sip%253A0123451010@sip.720.fr<sip%25253A0123451010(a)sip.720.fr> >> >>>. >> Remote-Party-ID: "linksys1" <sip:0123451005@sip.720.fr<sip%3A0123451005(a)sip.720.fr> >> <mailto:sip%3A0123451005@sip.720.fr<sip%253A0123451005(a)sip.720.fr> >> > >> <mailto:sip%3A0123451005@sip.720.fr<sip%253A0123451005(a)sip.720.fr> >> <mailto:sip%253A0123451005@sip.720.fr<sip%25253A0123451005(a)sip.720.fr> >> >>>;screen=yes;party=calling. >> Call-ID: 7dba9d80-33140832(a)192.168.0.120 >> <mailto:7dba9d80-33140832@192.168.0.120> >> <mailto:7dba9d80-33140832@192.168.0.120 >> <mailto:7dba9d80-33140832@192.168.0.120>>. >> >> CSeq: 102 INVITE. >> Max-Forwards: 50. >> Proxy-Authorization: Digest >> username="0123451005",realm="sip.720.fr <http://sip.720.fr> >> <http://sip.720.fr >> >",nonce="4933b0bd000000bb6b5025b195e2dac29e1a78759732fcfb",uri=" >> sip:0123451010@sip.720.fr <sip%3A0123451010(a)sip.720.fr> >> <mailto:sip%3A0123451010@sip.720.fr<sip%253A0123451010(a)sip.720.fr> >> > >> <mailto:sip%3A0123451010@sip.720.fr<sip%253A0123451010(a)sip.720.fr> >> <mailto:sip%253A0123451010@sip.720.fr<sip%25253A0123451010(a)sip.720.fr> >> >>",algorithm=MD5,response="2d6a83ad081b23632bbc40bcfb277daf",qop=auth,nc=00000001,cnonce="6dec9235". >> >> Contact: "linksys1" <sip:0123451005@192.168.0.120:5060 >> <http://sip:0123451005@192.168.0.120:5060> >> <http://sip:0123451005@192.168.0.120:5060>>. >> >> Expires: 240. >> User-Agent: Linksys/SPA941-5.1.8. >> Content-Length: 259. >> Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER. >> Supported: replaces. >> Content-Type: application/sdp. >> . >> v=0. >> o=- 316723 316723 IN IP4 192.168.0.120 <http://192.168.0.120> >> <http://192.168.0.120>. >> s=-. >> c=IN IP4 192.168.0.120 <http://192.168.0.120> >> <http://192.168.0.120>. >> >> t=0 0. >> m=audio 38544 RTP/AVP 18 0 8 101. >> a=rtpmap:18 G729a/8000. >> a=rtpmap:0 PCMU/8000. >> a=rtpmap:8 PCMA/8000. >> a=rtpmap:101 telephone-event/8000. >> a=fmtp:101 0-15. >> a=ptime:30. >> a=sendrecv. >> >> *** Here you have the INVITE message in the case Linksys => >> Thomson (call ok) >> >> U 2008/12/01 10:39:43.317899 77.246.81.162:25722 >> <http://77.246.81.162:25722> <http://77.246.81.162:25722> -> >> 77.246.81.132:5060 <http://77.246.81.132:5060> >> <http://77.246.81.132:5060> >> >> INVITE sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr>>> >> SIP/2.0. >> Via: SIP/2.0/UDP 192.168.0.120:5060;branch=z9hG4bK-30acba56. >> From: "linksys1" <sip:0123451005@sip.720.fr<sip%3A0123451005(a)sip.720.fr> >> <mailto:sip%3A0123451005@sip.720.fr<sip%253A0123451005(a)sip.720.fr> >> > >> <mailto:sip%3A0123451005@sip.720.fr<sip%253A0123451005(a)sip.720.fr> >> <mailto:sip%253A0123451005@sip.720.fr<sip%25253A0123451005(a)sip.720.fr> >> >>>;tag=4829c42d46f54ba1o0. >> To: "thomson1" <sip:0123451013@sip.720.fr<sip%3A0123451013(a)sip.720.fr> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> >>>. >> Remote-Party-ID: "linksys1" <sip:0123451005@sip.720.fr<sip%3A0123451005(a)sip.720.fr> >> <mailto:sip%3A0123451005@sip.720.fr<sip%253A0123451005(a)sip.720.fr> >> > >> <mailto:sip%3A0123451005@sip.720.fr<sip%253A0123451005(a)sip.720.fr> >> <mailto:sip%253A0123451005@sip.720.fr<sip%25253A0123451005(a)sip.720.fr> >> >>>;screen=yes;party=calling. >> Call-ID: ebfea81d-6dcc3871(a)192.168.0.120 >> <mailto:ebfea81d-6dcc3871@192.168.0.120> >> <mailto:ebfea81d-6dcc3871@192.168.0.120 >> <mailto:ebfea81d-6dcc3871@192.168.0.120>>. >> >> CSeq: 102 INVITE. >> Max-Forwards: 50. >> Proxy-Authorization: Digest >> username="0123451005",realm="sip.720.fr <http://sip.720.fr> >> <http://sip.720.fr >> >",nonce="4933b20b000000bcd4130811017007669127457c07480a0e",uri=" >> sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> >>",algorithm=MD5,response="a888badf3b4a5d787f2a763dd8fd8c28",qop=auth,nc=00000001,cnonce="7405f5b". >> Contact: "linksys1" <sip:0123451005@192.168.0.120:5060 >> <http://sip:0123451005@192.168.0.120:5060> >> <http://sip:0123451005@192.168.0.120:5060>>. >> >> Expires: 240. >> User-Agent: Linksys/SPA941-5.1.8. >> Content-Length: 259. >> Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER. >> Supported: replaces. >> Content-Type: application/sdp. >> . >> v=0. >> o=- 350059 350059 IN IP4 192.168.0.120 <http://192.168.0.120> >> <http://192.168.0.120>. >> s=-. >> c=IN IP4 192.168.0.120 <http://192.168.0.120> >> <http://192.168.0.120>. >> >> t=0 0. >> m=audio 38546 RTP/AVP 18 0 8 101. >> a=rtpmap:18 G729a/8000. >> a=rtpmap:0 PCMU/8000. >> a=rtpmap:8 PCMA/8000. >> a=rtpmap:101 telephone-event/8000. >> a=fmtp:101 0-15. >> a=ptime:30. >> a=sendrecv. >> >> *** Here you have the INVITE message in the case Thomson => >> Linksys (call not ok) >> >> U 2008/12/01 10:41:54.428224 77.246.81.162:24507 >> <http://77.246.81.162:24507> <http://77.246.81.162:24507> -> >> 77.246.81.132:5060 <http://77.246.81.132:5060> >> <http://77.246.81.132:5060> >> >> INVITE sip:0123451010@sip.720.fr:5060;user=phone SIP/2.0. >> Via: SIP/2.0/UDP >> 192.168.0.184:5060;branch=z9hG4bK7920248682981536932-1809931. >> From: >> "thomson1"<sip:0123451013@sip.720.fr:5060 >> ;user=phone>;tag=c0a80101-1b9de5. >> To: <sip:0123451010@sip.720.fr:5060;user=phone>. >> Call-ID: 1bc719-c0a80101-0-2(a)192.168.0.184 >> <mailto:1bc719-c0a80101-0-2@192.168.0.184> >> <mailto:1bc719-c0a80101-0-2@192.168.0.184 >> <mailto:1bc719-c0a80101-0-2@192.168.0.184>>. >> >> CSeq: 2 INVITE. >> Max-Forwards: 70. >> Supported: timer, replaces. >> Session-Expires: 1800. >> Proxy-Authorization: Digest username="0123451013", >> realm="sip.720.fr <http://sip.720.fr> <http://sip.720.fr>", >> nonce="4933b28e000000bf60feb103ab85ee5f758ec510d7773f66", >> uri="sip:0123451010@sip.720.fr:5060;user=phone", >> response="1eb59cbc25d6db05fafcd5d8b915da4a", algorithm=MD5, >> qop=auth, cnonce="1b9e0b", nc=00000001. >> >> Allow: >> >> INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,SUBSCRIBE,NOTIFY,UPDATE,REFER,REGISTER,INFO. >> Contact: <sip:0123451013@192.168.0.184:5060;user=phone>. >> User-Agent: THOMSON thomson1 hw5 fw1.63 00-14-7F-00-5E-0A. >> Allow-Events: refer,dialog,message-summary,check-sync,talk,hold. >> Content-Type: application/sdp. >> Content-Length: 299. >> . >> v=0. >> o=0123451013 1809894 1809894 IN IP4 192.168.0.184 >> <http://192.168.0.184> <http://192.168.0.184>. >> s=-. >> c=IN IP4 192.168.0.184 <http://192.168.0.184> >> <http://192.168.0.184>. >> >> t=0 0. >> m=audio 41000 RTP/AVP 8 0 18 4 96. >> a=rtpmap:8 PCMA/8000. >> a=rtpmap:0 PCMU/8000. >> a=rtpmap:18 G729/8000. >> a=fmtp:18 annexb=no. >> a=rtpmap:4 G723/8000. >> a=rtpmap:96 telephone-event/8000. >> a=fmtp:96 0-15. >> a=sendrecv. >> >> *** Here you have the INVITE message in the case Thomson => >> Thomson (call not ok) >> >> U 2008/12/01 10:43:41.340288 77.246.81.162:30201 >> <http://77.246.81.162:30201> <http://77.246.81.162:30201> -> >> >> 77.246.81.132:5060 <http://77.246.81.132:5060> >> <http://77.246.81.132:5060> >> >> INVITE sip:0123451013@sip.720.fr:5060;user=phone SIP/2.0. >> Via: SIP/2.0/UDP >> 192.168.0.185:5060;branch=z9hG4bK9142470814203758154-1862706. >> From: >> "thomson2"<sip:0123451014@sip.720.fr:5060 >> ;user=phone>;tag=c0a80101-1c6c04. >> To: <sip:0123451013@sip.720.fr:5060;user=phone>. >> Call-ID: 1c93e7-c0a80101-0-2(a)192.168.0.185 >> <mailto:1c93e7-c0a80101-0-2@192.168.0.185> >> <mailto:1c93e7-c0a80101-0-2@192.168.0.185 >> <mailto:1c93e7-c0a80101-0-2@192.168.0.185>>. >> >> CSeq: 2 INVITE. >> Max-Forwards: 70. >> Supported: timer, replaces. >> Session-Expires: 1800.Proxy-Authorization: Digest >> username="0123451014", realm="sip.720.fr <http://sip.720.fr> >> <http://sip.720.fr>", >> nonce="4933b2f9000000c25f1b77c7d99d35ceeb25c03a20f5e153", >> uri="sip:0123451013@sip.720.fr:5060;user=phone", >> response="2c46b135e8453fce29308c03cf89aac5", algorithm=MD5, >> qop=auth, cnonce="1c6c33", nc=00 >> >> 000001. >> Allow: >> >> INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,SUBSCRIBE,NOTIFY,UPDATE,REFER,REGISTER,INFO. >> Contact: <sip:0123451014@192.168.0.185:5060;user=phone>. >> User-Agent: THOMSON thomson1 hw5 fw1.63 00-14-7F-E1-63-34. >> Allow-Events: refer,dialog,message-summary,check-sync,talk,hold. >> Content-Type: application/sdp. >> Content-Length: 299. >> . >> v=0. >> o=0123451014 1862661 1862661 IN IP4 192.168.0.185 >> <http://192.168.0.185> <http://192.168.0.185>. >> >> s=-. >> c=IN IP4 192.168.0.185 <http://192.168.0.185> >> <http://192.168.0.185>. >> >> t=0 0. >> m=audio 41000 RTP/AVP 8 0 18 4 96. >> a=rtpmap:8 PCMA/8000. >> a=rtpmap:0 PCMU/8000. >> a=rtpmap:18 G729/8000. >> a=fmtp:18 annexb=no. >> a=rtpmap:4 G723/8000. >> a=rtpmap:96 telephone-event/8000. >> a=fmtp:96 0-15. >> a=sendrecv. >> >> >> >> It's strange ... >> >> .Sam. >> >> >> On Fri, Nov 28, 2008 at 12:52 PM, Klaus Darilion >> <klaus.mailinglists(a)pernau.at >> <mailto:klaus.mailinglists@pernau.at> >> <mailto:klaus.mailinglists@pernau.at >> <mailto:klaus.mailinglists@pernau.at>>> wrote: >> >> the user=phone parameter in the Contact is probably not the >> problem >> - there can be any parameter there. Except the client does not >> accept its own contact. >> >> I suspect a NAT problem >> >> regards >> klaus >> >> Samuel Muller schrieb: >> >> Hello all, >> >> I've a little problem with the SIP phone Thomson ST2030. >> When it registers, it auto-adds ";user=phone" in all the >> fields >> it can be. >> The problem is that it can't be called due to the contact >> header, kamailio can't found the phone. >> >> I tried to delete the filed during the REGISTER and the >> PROXY >> AUTH processes, with no success ... >> >> If someone has a solution, many thanks ! >> >> -- -- >> kamailio.cfg : >> -- -- >> ... >> # ;user=phone hack >> if (search("^Contact:.*;user=phone")) >> { >> xlog("L_INFO", "-> user=phone found, >> remove it - >> F=$fu ContactHF=$ct"); >> replace_all(";user=phone", "\r\n"); >> #subst("/;user=phone$;$")) >> } >> ... >> >> => all the logs here : >> >> -- -- >> SQL result >> -- -- >> >> Database: openser >> SQL query: SELECT * FROM `location` WHERE `id` = 383 >> LIMIT 0, 30 ; >> >> id 383 >> username 0123451013 >> domain sip.720.fr <http://sip.720.fr> >> <http://sip.720.fr> >> <http://sip.720.fr> >> >> contact sip:0123451013@192.168.0.158:5060;user=phone >> received sip:77.246.81.162:1902 >> <http://77.246.81.162:1902> <http://77.246.81.162:1902> >> <http://77.246.81.162:1902> >> >> path NULL >> expires 2008-11-28 13:02:16 >> q 0.00 >> callid 18786315-c0a80101-5-a(a)192.168.0.158 >> <mailto:18786315-c0a80101-5-a@192.168.0.158> >> <mailto:18786315-c0a80101-5-a@192.168.0.158 >> <mailto:18786315-c0a80101-5-a@192.168.0.158>> >> <mailto:18786315-c0a80101-5-a@192.168.0.158 >> <mailto:18786315-c0a80101-5-a@192.168.0.158> >> <mailto:18786315-c0a80101-5-a@192.168.0.158 >> <mailto:18786315-c0a80101-5-a@192.168.0.158>>> >> >> cseq 270 >> last_modified 2008-11-28 12:02:16 >> flags 0 >> cflags 64 >> user_agent THOMSON ST2030 hw5 fw1.63 00-14-7F-00-5E-0A >> socket udp:77.246.81.132:5060 >> <http://77.246.81.132:5060> >> <http://77.246.81.132:5060> <http://77.246.81.132:5060> >> >> >> methods NULL >> >> -- -- >> kamailio REGISTER sip buffer >> -- -- >> >> REGISTER sip:sip.720.fr <http://sip.720.fr> >> <http://sip.720.fr> >> <http://sip.720.fr>;user=phone SIP/2.0 >> >> Via: SIP/2.0/UDP >> 192.168.0.158:5060 >> ;branch=z9hG4bK363142985921875976-158787787 >> From: >> <sip:0123451013@sip.720.fr:5060 >> ;user=phone>;tag=c0a80101-976e8ab >> To: <sip:0123451013@sip.720.fr:5060;user=phone> >> Call-ID: 18786315-c0a80101-5-a(a)192.168.0.158 >> <mailto:18786315-c0a80101-5-a@192.168.0.158> >> <mailto:18786315-c0a80101-5-a@192.168.0.158 >> <mailto:18786315-c0a80101-5-a@192.168.0.158>> >> <mailto:18786315-c0a80101-5-a@192.168.0.158 >> <mailto:18786315-c0a80101-5-a@192.168.0.158> >> <mailto:18786315-c0a80101-5-a@192.168.0.158 >> <mailto:18786315-c0a80101-5-a@192.168.0.158>>> >> >> CSeq: 250 REGISTER >> Max-Forwards: 69 >> Expires: 3600 >> Contact: <sip:0123451013@192.168.0.158:5060;user=phone> >> Authorization: Digest username="0123451013", >> realm="sip.720.fr <http://sip.720.fr> >> <http://sip.720.fr> <http://sip.720.fr>", >> nonce="492f8a92000000697e7fefd30ce752d7e50c6166da2cc6e2", >> uri="sip:sip.720.fr <http://sip.720.fr> >> <http://sip.720.fr> <http://sip.720.fr>", >> >> response="37f8ec824ba77eb37583f38f2a509f77", >> >> algorithm=MD5, qop=auth, cnonce="976e8cb", nc=00000001 >> User-Agent: THOMSON ST2030 hw5 fw1.63 00-14-7F-00-5E-0A >> Allow-Events: >> refer,dialog,message-summary,check-sync,talk,hold >> Content-Length: 0 >> >> -- -- >> ngrep log : >> -- -- >> >> U 2008/11/28 12:13:59.813649 77.246.81.162:8680 >> <http://77.246.81.162:8680> >> <http://77.246.81.162:8680> <http://77.246.81.162:8680> -> >> >> 77.246.81.132:5060 <http://77.246.81.132:5060> >> <http://77.246.81.132:5060> >> <http://77.246.81.132:5060> >> INVITE sip:0123451013@sip.720.fr<sip%3A0123451013(a)sip.720.fr> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> >> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> <mailto:sip%25253A0123451013@sip.720.fr<sip%2525253A0123451013(a)sip.720.fr>>>> >> SIP/2.0. >> >> >> Via: SIP/2.0/UDP 192.168.0.113:5060 >> ;branch=z9hG4bK-eb23842c. >> From: "Sam" <sip:0123451010@sip.720.fr<sip%3A0123451010(a)sip.720.fr> >> <mailto:sip%3A0123451010@sip.720.fr<sip%253A0123451010(a)sip.720.fr> >> > >> <mailto:sip%3A0123451010@sip.720.fr<sip%253A0123451010(a)sip.720.fr> >> <mailto:sip%253A0123451010@sip.720.fr<sip%25253A0123451010(a)sip.720.fr> >> >> >> <mailto:sip%3A0123451010@sip.720.fr<sip%253A0123451010(a)sip.720.fr> >> <mailto:sip%253A0123451010@sip.720.fr<sip%25253A0123451010(a)sip.720.fr> >> > >> <mailto:sip%253A0123451010@sip.720.fr<sip%25253A0123451010(a)sip.720.fr> >> <mailto:sip%25253A0123451010@sip.720.fr<sip%2525253A0123451010(a)sip.720.fr> >> >>>>;tag=4209e88c969ca7dfo0. >> >> To: "st2030" <sip:0123451013@sip.720.fr<sip%3A0123451013(a)sip.720.fr> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> >> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> <mailto:sip%25253A0123451013@sip.720.fr<sip%2525253A0123451013(a)sip.720.fr> >> >>>>. >> >> Remote-Party-ID: "Sam" <sip:0123451010@sip.720.fr<sip%3A0123451010(a)sip.720.fr> >> <mailto:sip%3A0123451010@sip.720.fr<sip%253A0123451010(a)sip.720.fr> >> > >> <mailto:sip%3A0123451010@sip.720.fr<sip%253A0123451010(a)sip.720.fr> >> <mailto:sip%253A0123451010@sip.720.fr<sip%25253A0123451010(a)sip.720.fr> >> >> >> <mailto:sip%3A0123451010@sip.720.fr<sip%253A0123451010(a)sip.720.fr> >> <mailto:sip%253A0123451010@sip.720.fr<sip%25253A0123451010(a)sip.720.fr> >> > >> <mailto:sip%253A0123451010@sip.720.fr<sip%25253A0123451010(a)sip.720.fr> >> <mailto:sip%25253A0123451010@sip.720.fr<sip%2525253A0123451010(a)sip.720.fr> >> >>>>;screen=yes;party=calling. >> >> Call-ID: 39d2f3d0-b283756b(a)192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113> >> <mailto:39d2f3d0-b283756b@192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113>> >> <mailto:39d2f3d0-b283756b@192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113> >> <mailto:39d2f3d0-b283756b@192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113>>>. >> >> CSeq: 102 INVITE. >> Max-Forwards: 50. >> Proxy-Authorization: Digest >> username="0123451010",realm="sip.720.fr >> <http://sip.720.fr> <http://sip.720.fr> >> <http://sip.720.fr >> >",nonce="492fd3a300000094c9e8b4f3805f7f96dc3f36f981a64570",uri=" >> sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> >> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> <mailto:sip%25253A0123451013@sip.720.fr<sip%2525253A0123451013(a)sip.720.fr> >> >>>",algorithm=MD5,response="1538e1ac3e3181f8bfb6f473f2470a6a",qop=auth,nc=00000001,cnonce="7c8a76fd". >> >> >> Contact: "Sam" <sip:0123451010@192.168.0.113:5060 >> <http://sip:0123451010@192.168.0.113:5060> >> <http://sip:0123451010@192.168.0.113:5060> >> <http://sip:0123451010@192.168.0.113:5060>>. >> >> Expires: 240. >> User-Agent: Linksys/SPA941-5.1.8. >> Content-Length: 263. >> Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, >> PRACK, >> REFER. >> Supported: 100rel, replaces. >> Content-Type: application/sdp. >> . >> v=0. >> o=- 33629308 33629308 IN IP4 192.168.0.113 >> <http://192.168.0.113> >> <http://192.168.0.113> <http://192.168.0.113>. >> >> s=-. >> c=IN IP4 192.168.0.113 <http://192.168.0.113> >> <http://192.168.0.113> >> <http://192.168.0.113>. >> >> t=0 0. >> m=audio 35692 RTP/AVP 18 0 8 101. >> a=rtpmap:18 G729a/8000. >> a=rtpmap:0 PCMU/8000. >> a=rtpmap:8 PCMA/8000. >> a=rtpmap:101 telephone-event/8000. >> a=fmtp:101 0-15. >> a=ptime:30. >> a=sendrecv. >> >> >> U 2008/11/28 12:13:59.820056 77.246.81.132:5060 >> <http://77.246.81.132:5060> >> <http://77.246.81.132:5060> <http://77.246.81.132:5060> -> >> >> 77.246.81.162:8680 <http://77.246.81.162:8680> >> <http://77.246.81.162:8680> >> <http://77.246.81.162:8680> >> >> SIP/2.0 100 Trying. >> Via: SIP/2.0/UDP >> 192.168.0.113:5060 >> ;branch=z9hG4bK-eb23842c;rport=8680;received=77.246.81.162 >> <http://77.246.81.162> >> <http://77.246.81.162> <http://77.246.81.162>. >> >> From: "Sam" <sip:0123451010@sip.720.fr<sip%3A0123451010(a)sip.720.fr> >> <mailto:sip%3A0123451010@sip.720.fr<sip%253A0123451010(a)sip.720.fr> >> > >> <mailto:sip%3A0123451010@sip.720.fr<sip%253A0123451010(a)sip.720.fr> >> <mailto:sip%253A0123451010@sip.720.fr<sip%25253A0123451010(a)sip.720.fr> >> >> >> <mailto:sip%3A0123451010@sip.720.fr<sip%253A0123451010(a)sip.720.fr> >> <mailto:sip%253A0123451010@sip.720.fr<sip%25253A0123451010(a)sip.720.fr> >> > >> <mailto:sip%253A0123451010@sip.720.fr<sip%25253A0123451010(a)sip.720.fr> >> <mailto:sip%25253A0123451010@sip.720.fr<sip%2525253A0123451010(a)sip.720.fr> >> >>>>;tag=4209e88c969ca7dfo0. >> >> To: "st2030" <sip:0123451013@sip.720.fr<sip%3A0123451013(a)sip.720.fr> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> >> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> <mailto:sip%25253A0123451013@sip.720.fr<sip%2525253A0123451013(a)sip.720.fr> >> >>>>. >> >> Call-ID: 39d2f3d0-b283756b(a)192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113> >> <mailto:39d2f3d0-b283756b@192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113>> >> <mailto:39d2f3d0-b283756b@192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113> >> <mailto:39d2f3d0-b283756b@192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113>>>. >> >> CSeq: 102 INVITE. >> Server: 720 DEGRES SIP PROXY. >> Content-Length: 0. >> Warning: 392 77.246.81.132:5060 >> <http://77.246.81.132:5060> <http://77.246.81.132:5060> >> <http://77.246.81.132:5060> "Noisy feedback tells: >> pid=14141 >> req_src_ip=77.246.81.162 <http://77.246.81.162> >> <http://77.246.81.162> >> <http://77.246.81.162> req_src_port=8680 >> in_uri=sip:0123451013@sip.720.fr<sip%3A0123451013(a)sip.720.fr> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> >> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> <mailto:sip%25253A0123451013@sip.720.fr<sip%2525253A0123451013(a)sip.720.fr> >> >>> >> >> out_uri=sip:0123451013@sip.720.fr<sip%3A0123451013(a)sip.720.fr> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> >> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> <mailto:sip%25253A0123451013@sip.720.fr<sip%2525253A0123451013(a)sip.720.fr>>>> >> via_cnt==1". >> >> . >> >> >> U 2008/11/28 12:13:59.882639 77.246.81.132:5060 >> <http://77.246.81.132:5060> >> <http://77.246.81.132:5060> <http://77.246.81.132:5060> -> >> >> 77.246.81.162:1902 <http://77.246.81.162:1902> >> <http://77.246.81.162:1902> >> <http://77.246.81.162:1902> >> >> INVITE sip:0123451013@192.168.0.158:5060;user=phone >> SIP/2.0. >> Record-Route: <sip:77.246.81.132 <http://77.246.81.132> >> <http://77.246.81.132> >> <http://77.246.81.132 >> >;lr=on;ftag=4209e88c969ca7dfo0;nat=yes;vsf=dTRjN2NvOSh5O2l3chRUKWUpZWo5MGkrLFxGBRldBw-->. >> Via: SIP/2.0/UDP 77.246.81.132 <http://77.246.81.132> >> <http://77.246.81.132> >> <http://77.246.81.132>;branch=z9hG4bK821.3a570854.0. >> Via: SIP/2.0/UDP >> 192.168.0.113:5060;rport=8680;received=77.246.81.162 >> <http://77.246.81.162> >> <http://77.246.81.162> >> <http://77.246.81.162>;branch=z9hG4bK-eb23842c. >> >> From: "Anonymous" >> <sip:anonymous@anonymous.invalid>;tag=4209e88c969ca7dfo0. >> To: "st2030" <sip:0123451013@sip.720.fr<sip%3A0123451013(a)sip.720.fr> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> >> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> <mailto:sip%25253A0123451013@sip.720.fr<sip%2525253A0123451013(a)sip.720.fr> >> >>>>. >> >> Call-ID: 39d2f3d0-b283756b(a)192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113> >> <mailto:39d2f3d0-b283756b@192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113>> >> <mailto:39d2f3d0-b283756b@192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113> >> <mailto:39d2f3d0-b283756b@192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113>>>. >> >> CSeq: 102 INVITE. >> Max-Forwards: 49. >> Contact: "Sam" <sip:0123451010@77.246.81.162:8680 >> <http://sip:0123451010@77.246.81.162:8680> >> <http://sip:0123451010@77.246.81.162:8680> >> <http://sip:0123451010@77.246.81.162:8680>>. >> >> Expires: 240. >> User-Agent: Linksys/SPA941-5.1.8. >> Content-Length: 281. >> Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, >> PRACK, >> REFER. >> Supported: 100rel, replaces. >> Content-Type: application/sdp. >> Privacy: id. >> Remote-Party-ID: >> <<null>>;party=caller;privacy=yes;screen=no. >> . >> v=0. >> o=- 33629308 33629308 IN IP4 192.168.0.113 >> <http://192.168.0.113> >> <http://192.168.0.113> <http://192.168.0.113>. >> >> s=-. >> c=IN IP4 77.246.81.133 <http://77.246.81.133> >> <http://77.246.81.133> >> <http://77.246.81.133>. >> >> t=0 0. >> m=audio 35132 RTP/AVP 18 0 8 101. >> a=rtpmap:18 G729a/8000. >> a=rtpmap:0 PCMU/8000. >> a=rtpmap:8 PCMA/8000. >> a=rtpmap:101 telephone-event/8000. >> a=fmtp:101 0-15. >> a=ptime:30. >> a=sendrecv. >> a=nortpproxy:yes. >> >> >> U 2008/11/28 12:14:00.273883 77.246.81.132:5060 >> <http://77.246.81.132:5060> >> <http://77.246.81.132:5060> <http://77.246.81.132:5060> -> >> >> 77.246.81.162:1902 <http://77.246.81.162:1902> >> <http://77.246.81.162:1902> >> <http://77.246.81.162:1902> >> >> INVITE sip:0123451013@192.168.0.158:5060;user=phone >> SIP/2.0. >> Record-Route: <sip:77.246.81.132 <http://77.246.81.132> >> <http://77.246.81.132> >> <http://77.246.81.132 >> >;lr=on;ftag=4209e88c969ca7dfo0;nat=yes;vsf=dTRjN2NvOSh5O2l3chRUKWUpZWo5MGkrLFxGBRldBw-->. >> Via: SIP/2.0/UDP 77.246.81.132 <http://77.246.81.132> >> <http://77.246.81.132> >> <http://77.246.81.132>;branch=z9hG4bK821.3a570854.0. >> Via: SIP/2.0/UDP >> 192.168.0.113:5060;rport=8680;received=77.246.81.162 >> <http://77.246.81.162> >> <http://77.246.81.162> >> <http://77.246.81.162>;branch=z9hG4bK-eb23842c. >> >> From: "Anonymous" >> <sip:anonymous@anonymous.invalid>;tag=4209e88c969ca7dfo0. >> To: "st2030" <sip:0123451013@sip.720.fr<sip%3A0123451013(a)sip.720.fr> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> >> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> <mailto:sip%25253A0123451013@sip.720.fr<sip%2525253A0123451013(a)sip.720.fr> >> >>>>. >> >> Call-ID: 39d2f3d0-b283756b(a)192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113> >> <mailto:39d2f3d0-b283756b@192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113>> >> <mailto:39d2f3d0-b283756b@192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113> >> <mailto:39d2f3d0-b283756b@192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113>>>. >> >> CSeq: 102 INVITE. >> Max-Forwards: 49. >> Contact: "Sam" <sip:0123451010@77.246.81.162:8680 >> <http://sip:0123451010@77.246.81.162:8680> >> <http://sip:0123451010@77.246.81.162:8680> >> <http://sip:0123451010@77.246.81.162:8680>>. >> >> Expires: 240. >> User-Agent: Linksys/SPA941-5.1.8. >> Content-Length: 281. >> Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, >> PRACK, >> REFER. >> Supported: 100rel, replaces. >> Content-Type: application/sdp. >> Privacy: id. >> Remote-Party-ID: >> <<null>>;party=caller;privacy=yes;screen=no. >> . >> v=0. >> o=- 33629308 33629308 IN IP4 192.168.0.113 >> <http://192.168.0.113> >> <http://192.168.0.113> <http://192.168.0.113>. >> >> s=-. >> c=IN IP4 77.246.81.133 <http://77.246.81.133> >> <http://77.246.81.133> >> <http://77.246.81.133>. >> >> t=0 0. >> m=audio 35132 RTP/AVP 18 0 8 101. >> a=rtpmap:18 G729a/8000. >> a=rtpmap:0 PCMU/8000. >> a=rtpmap:8 PCMA/8000. >> a=rtpmap:101 telephone-event/8000. >> a=fmtp:101 0-15. >> a=ptime:30. >> a=sendrecv. >> a=nortpproxy:yes. >> >> >> U 2008/11/28 12:14:01.272604 77.246.81.132:5060 >> <http://77.246.81.132:5060> >> <http://77.246.81.132:5060> <http://77.246.81.132:5060> -> >> >> 77.246.81.162:1902 <http://77.246.81.162:1902> >> <http://77.246.81.162:1902> >> <http://77.246.81.162:1902> >> >> INVITE sip:0123451013@192.168.0.158:5060;user=phone >> SIP/2.0. >> Record-Route: <sip:77.246.81.132 <http://77.246.81.132> >> <http://77.246.81.132> >> <http://77.246.81.132 >> >;lr=on;ftag=4209e88c969ca7dfo0;nat=yes;vsf=dTRjN2NvOSh5O2l3chRUKWUpZWo5MGkrLFxGBRldBw-->. >> Via: SIP/2.0/UDP 77.246.81.132 <http://77.246.81.132> >> <http://77.246.81.132> >> <http://77.246.81.132>;branch=z9hG4bK821.3a570854.0. >> Via: SIP/2.0/UDP >> 192.168.0.113:5060;rport=8680;received=77.246.81.162 >> <http://77.246.81.162> >> <http://77.246.81.162> >> <http://77.246.81.162>;branch=z9hG4bK-eb23842c. >> >> From: "Anonymous" >> <sip:anonymous@anonymous.invalid>;tag=4209e88c969ca7dfo0. >> To: "st2030" <sip:0123451013@sip.720.fr<sip%3A0123451013(a)sip.720.fr> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> >> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> <mailto:sip%25253A0123451013@sip.720.fr<sip%2525253A0123451013(a)sip.720.fr> >> >>>>. >> >> Call-ID: 39d2f3d0-b283756b(a)192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113> >> <mailto:39d2f3d0-b283756b@192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113>> >> <mailto:39d2f3d0-b283756b@192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113> >> <mailto:39d2f3d0-b283756b@192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113>>>. >> >> CSeq: 102 INVITE. >> Max-Forwards: 49. >> Contact: "Sam" <sip:0123451010@77.246.81.162:8680 >> <http://sip:0123451010@77.246.81.162:8680> >> <http://sip:0123451010@77.246.81.162:8680> >> <http://sip:0123451010@77.246.81.162:8680>>. >> >> Expires: 240. >> User-Agent: Linksys/SPA941-5.1.8. >> Content-Length: 281. >> Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, >> PRACK, >> REFER. >> Supported: 100rel, replaces. >> Content-Type: application/sdp. >> Privacy: id. >> Remote-Party-ID: >> <<null>>;party=caller;privacy=yes;screen=no. >> . >> v=0. >> o=- 33629308 33629308 IN IP4 192.168.0.113 >> <http://192.168.0.113> >> <http://192.168.0.113> <http://192.168.0.113>. >> >> s=-. >> c=IN IP4 77.246.81.133 <http://77.246.81.133> >> <http://77.246.81.133> >> <http://77.246.81.133>. >> >> t=0 0. >> m=audio 35132 RTP/AVP 18 0 8 101. >> a=rtpmap:18 G729a/8000. >> a=rtpmap:0 PCMU/8000. >> a=rtpmap:8 PCMA/8000. >> a=rtpmap:101 telephone-event/8000. >> a=fmtp:101 0-15. >> a=ptime:30. >> a=sendrecv. >> a=nortpproxy:yes. >> >> >> U 2008/11/28 12:14:03.283852 77.246.81.132:5060 >> <http://77.246.81.132:5060> >> <http://77.246.81.132:5060> <http://77.246.81.132:5060> -> >> >> 77.246.81.162:1902 <http://77.246.81.162:1902> >> <http://77.246.81.162:1902> >> <http://77.246.81.162:1902> >> >> INVITE sip:0123451013@192.168.0.158:5060;user=phone >> SIP/2.0. >> Record-Route: <sip:77.246.81.132 <http://77.246.81.132> >> <http://77.246.81.132> >> <http://77.246.81.132 >> >;lr=on;ftag=4209e88c969ca7dfo0;nat=yes;vsf=dTRjN2NvOSh5O2l3chRUKWUpZWo5MGkrLFxGBRldBw-->. >> Via: SIP/2.0/UDP 77.246.81.132 <http://77.246.81.132> >> <http://77.246.81.132> >> <http://77.246.81.132>;branch=z9hG4bK821.3a570854.0. >> Via: SIP/2.0/UDP >> 192.168.0.113:5060;rport=8680;received=77.246.81.162 >> <http://77.246.81.162> >> <http://77.246.81.162> >> <http://77.246.81.162>;branch=z9hG4bK-eb23842c. >> >> From: "Anonymous" >> <sip:anonymous@anonymous.invalid>;tag=4209e88c969ca7dfo0. >> To: "st2030" <sip:0123451013@sip.720.fr<sip%3A0123451013(a)sip.720.fr> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> >> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> <mailto:sip%25253A0123451013@sip.720.fr<sip%2525253A0123451013(a)sip.720.fr> >> >>>>. >> >> Call-ID: 39d2f3d0-b283756b(a)192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113> >> <mailto:39d2f3d0-b283756b@192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113>> >> <mailto:39d2f3d0-b283756b@192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113> >> <mailto:39d2f3d0-b283756b@192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113>>>. >> >> CSeq: 102 INVITE. >> Max-Forwards: 49. >> Contact: "Sam" <sip:0123451010@77.246.81.162:8680 >> <http://sip:0123451010@77.246.81.162:8680> >> <http://sip:0123451010@77.246.81.162:8680> >> <http://sip:0123451010@77.246.81.162:8680>>. >> >> Expires: 240. >> User-Agent: Linksys/SPA941-5.1.8. >> Content-Length: 281. >> Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, >> PRACK, >> REFER. >> Supported: 100rel, replaces. >> Content-Type: application/sdp. >> Privacy: id. >> Remote-Party-ID: >> <<null>>;party=caller;privacy=yes;screen=no. >> . >> v=0. >> o=- 33629308 33629308 IN IP4 192.168.0.113 >> <http://192.168.0.113> >> <http://192.168.0.113> <http://192.168.0.113>. >> >> s=-. >> c=IN IP4 77.246.81.133 <http://77.246.81.133> >> <http://77.246.81.133> >> <http://77.246.81.133>. >> >> t=0 0. >> m=audio 35132 RTP/AVP 18 0 8 101. >> a=rtpmap:18 G729a/8000. >> a=rtpmap:0 PCMU/8000. >> a=rtpmap:8 PCMA/8000. >> a=rtpmap:101 telephone-event/8000. >> a=fmtp:101 0-15. >> a=ptime:30. >> a=sendrecv. >> a=nortpproxy:yes. >> >> >> U 2008/11/28 12:14:04.905612 77.246.81.162:8680 >> <http://77.246.81.162:8680> >> <http://77.246.81.162:8680> <http://77.246.81.162:8680> -> >> >> 77.246.81.132:5060 <http://77.246.81.132:5060> >> <http://77.246.81.132:5060> >> <http://77.246.81.132:5060> >> CANCEL sip:0123451013@sip.720.fr<sip%3A0123451013(a)sip.720.fr> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> >> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> <mailto:sip%25253A0123451013@sip.720.fr<sip%2525253A0123451013(a)sip.720.fr>>>> >> SIP/2.0. >> >> >> Via: SIP/2.0/UDP 192.168.0.113:5060 >> ;branch=z9hG4bK-eb23842c. >> From: "Sam" <sip:0123451010@sip.720.fr<sip%3A0123451010(a)sip.720.fr> >> <mailto:sip%3A0123451010@sip.720.fr<sip%253A0123451010(a)sip.720.fr> >> > >> <mailto:sip%3A0123451010@sip.720.fr<sip%253A0123451010(a)sip.720.fr> >> <mailto:sip%253A0123451010@sip.720.fr<sip%25253A0123451010(a)sip.720.fr> >> >> >> <mailto:sip%3A0123451010@sip.720.fr<sip%253A0123451010(a)sip.720.fr> >> <mailto:sip%253A0123451010@sip.720.fr<sip%25253A0123451010(a)sip.720.fr> >> > >> <mailto:sip%253A0123451010@sip.720.fr<sip%25253A0123451010(a)sip.720.fr> >> <mailto:sip%25253A0123451010@ <sip%2525253A0123451010(a)sip.720.fr> > > ... > > [Message clipped] -- Samuel MULLER Ingénieur Reseaux & Telecom 720 DEGRES +33 (0)663 128 505 sml(a)720.fr

2 1

[Kamailio-Users] Thomson ST2030 SIP contact problem
by Samuel Muller 01 Dec '08

01 Dec '08

Hello all, I've a little problem with the SIP phone Thomson ST2030. When it registers, it auto-adds ";user=phone" in all the fields it can be. The problem is that it can't be called due to the contact header, kamailio can't found the phone. I tried to delete the filed during the REGISTER and the PROXY AUTH processes, with no success ... If someone has a solution, many thanks ! -- -- kamailio.cfg : -- -- ... # ;user=phone hack if (search("^Contact:.*;user=phone")) { xlog("L_INFO", "-> user=phone found, remove it - F=$fu ContactHF=$ct"); replace_all(";user=phone", "\r\n"); #subst("/;user=phone$;$")) } ... => all the logs here : -- -- SQL result -- -- Database: openser SQL query: SELECT * FROM `location` WHERE `id` = 383 LIMIT 0, 30 ; id 383 username 0123451013 domain sip.720.fr contact sip:0123451013@192.168.0.158:5060;user=phone received sip:77.246.81.162:1902 path NULL expires 2008-11-28 13:02:16 q 0.00 callid 18786315-c0a80101-5-a(a)192.168.0.158 cseq 270 last_modified 2008-11-28 12:02:16 flags 0 cflags 64 user_agent THOMSON ST2030 hw5 fw1.63 00-14-7F-00-5E-0A socket udp:77.246.81.132:5060 methods NULL -- -- kamailio REGISTER sip buffer -- -- REGISTER sip:sip.720.fr;user=phone SIP/2.0 Via: SIP/2.0/UDP 192.168.0.158:5060 ;branch=z9hG4bK363142985921875976-158787787 From: <sip:0123451013@sip.720.fr:5060;user=phone>;tag=c0a80101-976e8ab To: <sip:0123451013@sip.720.fr:5060;user=phone> Call-ID: 18786315-c0a80101-5-a(a)192.168.0.158 CSeq: 250 REGISTER Max-Forwards: 69 Expires: 3600 Contact: <sip:0123451013@192.168.0.158:5060;user=phone> Authorization: Digest username="0123451013", realm="sip.720.fr", nonce="492f8a92000000697e7fefd30ce752d7e50c6166da2cc6e2", uri="sip:sip.720.fr", response="37f8ec824ba77eb37583f38f2a509f77", algorithm=MD5, qop=auth, cnonce="976e8cb", nc=00000001 User-Agent: THOMSON ST2030 hw5 fw1.63 00-14-7F-00-5E-0A Allow-Events: refer,dialog,message-summary,check-sync,talk,hold Content-Length: 0 -- -- ngrep log : -- -- U 2008/11/28 12:13:59.813649 77.246.81.162:8680 -> 77.246.81.132:5060 INVITE sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr> SIP/2.0. Via: SIP/2.0/UDP 192.168.0.113:5060;branch=z9hG4bK-eb23842c. From: "Sam" <sip:0123451010@sip.720.fr <sip%3A0123451010(a)sip.720.fr> >;tag=4209e88c969ca7dfo0. To: "st2030" <sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr>>. Remote-Party-ID: "Sam" <sip:0123451010@sip.720.fr<sip%3A0123451010(a)sip.720.fr> >;screen=yes;party=calling. Call-ID: 39d2f3d0-b283756b(a)192.168.0.113. CSeq: 102 INVITE. Max-Forwards: 50. Proxy-Authorization: Digest username="0123451010",realm="sip.720.fr ",nonce="492fd3a300000094c9e8b4f3805f7f96dc3f36f981a64570",uri=" sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr> ",algorithm=MD5,response="1538e1ac3e3181f8bfb6f473f2470a6a",qop=auth,nc=00000001,cnonce="7c8a76fd". Contact: "Sam" <sip:0123451010@192.168.0.113:5060>. Expires: 240. User-Agent: Linksys/SPA941-5.1.8. Content-Length: 263. Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER. Supported: 100rel, replaces. Content-Type: application/sdp. . v=0. o=- 33629308 33629308 IN IP4 192.168.0.113. s=-. c=IN IP4 192.168.0.113. t=0 0. m=audio 35692 RTP/AVP 18 0 8 101. a=rtpmap:18 G729a/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:30. a=sendrecv. U 2008/11/28 12:13:59.820056 77.246.81.132:5060 -> 77.246.81.162:8680 SIP/2.0 100 Trying. Via: SIP/2.0/UDP 192.168.0.113:5060 ;branch=z9hG4bK-eb23842c;rport=8680;received=77.246.81.162. From: "Sam" <sip:0123451010@sip.720.fr <sip%3A0123451010(a)sip.720.fr> >;tag=4209e88c969ca7dfo0. To: "st2030" <sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr>>. Call-ID: 39d2f3d0-b283756b(a)192.168.0.113. CSeq: 102 INVITE. Server: 720 DEGRES SIP PROXY. Content-Length: 0. Warning: 392 77.246.81.132:5060 "Noisy feedback tells: pid=14141 req_src_ip=77.246.81.162 req_src_port=8680 in_uri=sip:0123451013@sip.720.fr<sip%3A0123451013(a)sip.720.fr>out_uri= sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr> via_cnt==1". . U 2008/11/28 12:13:59.882639 77.246.81.132:5060 -> 77.246.81.162:1902 INVITE sip:0123451013@192.168.0.158:5060;user=phone SIP/2.0. Record-Route: <sip:77.246.81.132 ;lr=on;ftag=4209e88c969ca7dfo0;nat=yes;vsf=dTRjN2NvOSh5O2l3chRUKWUpZWo5MGkrLFxGBRldBw-->. Via: SIP/2.0/UDP 77.246.81.132;branch=z9hG4bK821.3a570854.0. Via: SIP/2.0/UDP 192.168.0.113:5060;rport=8680;received=77.246.81.162 ;branch=z9hG4bK-eb23842c. From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=4209e88c969ca7dfo0. To: "st2030" <sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr>>. Call-ID: 39d2f3d0-b283756b(a)192.168.0.113. CSeq: 102 INVITE. Max-Forwards: 49. Contact: "Sam" <sip:0123451010@77.246.81.162:8680>. Expires: 240. User-Agent: Linksys/SPA941-5.1.8. Content-Length: 281. Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER. Supported: 100rel, replaces. Content-Type: application/sdp. Privacy: id. Remote-Party-ID: <<null>>;party=caller;privacy=yes;screen=no. . v=0. o=- 33629308 33629308 IN IP4 192.168.0.113. s=-. c=IN IP4 77.246.81.133. t=0 0. m=audio 35132 RTP/AVP 18 0 8 101. a=rtpmap:18 G729a/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:30. a=sendrecv. a=nortpproxy:yes. U 2008/11/28 12:14:00.273883 77.246.81.132:5060 -> 77.246.81.162:1902 INVITE sip:0123451013@192.168.0.158:5060;user=phone SIP/2.0. Record-Route: <sip:77.246.81.132 ;lr=on;ftag=4209e88c969ca7dfo0;nat=yes;vsf=dTRjN2NvOSh5O2l3chRUKWUpZWo5MGkrLFxGBRldBw-->. Via: SIP/2.0/UDP 77.246.81.132;branch=z9hG4bK821.3a570854.0. Via: SIP/2.0/UDP 192.168.0.113:5060;rport=8680;received=77.246.81.162 ;branch=z9hG4bK-eb23842c. From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=4209e88c969ca7dfo0. To: "st2030" <sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr>>. Call-ID: 39d2f3d0-b283756b(a)192.168.0.113. CSeq: 102 INVITE. Max-Forwards: 49. Contact: "Sam" <sip:0123451010@77.246.81.162:8680>. Expires: 240. User-Agent: Linksys/SPA941-5.1.8. Content-Length: 281. Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER. Supported: 100rel, replaces. Content-Type: application/sdp. Privacy: id. Remote-Party-ID: <<null>>;party=caller;privacy=yes;screen=no. . v=0. o=- 33629308 33629308 IN IP4 192.168.0.113. s=-. c=IN IP4 77.246.81.133. t=0 0. m=audio 35132 RTP/AVP 18 0 8 101. a=rtpmap:18 G729a/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:30. a=sendrecv. a=nortpproxy:yes. U 2008/11/28 12:14:01.272604 77.246.81.132:5060 -> 77.246.81.162:1902 INVITE sip:0123451013@192.168.0.158:5060;user=phone SIP/2.0. Record-Route: <sip:77.246.81.132 ;lr=on;ftag=4209e88c969ca7dfo0;nat=yes;vsf=dTRjN2NvOSh5O2l3chRUKWUpZWo5MGkrLFxGBRldBw-->. Via: SIP/2.0/UDP 77.246.81.132;branch=z9hG4bK821.3a570854.0. Via: SIP/2.0/UDP 192.168.0.113:5060;rport=8680;received=77.246.81.162 ;branch=z9hG4bK-eb23842c. From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=4209e88c969ca7dfo0. To: "st2030" <sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr>>. Call-ID: 39d2f3d0-b283756b(a)192.168.0.113. CSeq: 102 INVITE. Max-Forwards: 49. Contact: "Sam" <sip:0123451010@77.246.81.162:8680>. Expires: 240. User-Agent: Linksys/SPA941-5.1.8. Content-Length: 281. Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER. Supported: 100rel, replaces. Content-Type: application/sdp. Privacy: id. Remote-Party-ID: <<null>>;party=caller;privacy=yes;screen=no. . v=0. o=- 33629308 33629308 IN IP4 192.168.0.113. s=-. c=IN IP4 77.246.81.133. t=0 0. m=audio 35132 RTP/AVP 18 0 8 101. a=rtpmap:18 G729a/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:30. a=sendrecv. a=nortpproxy:yes. U 2008/11/28 12:14:03.283852 77.246.81.132:5060 -> 77.246.81.162:1902 INVITE sip:0123451013@192.168.0.158:5060;user=phone SIP/2.0. Record-Route: <sip:77.246.81.132 ;lr=on;ftag=4209e88c969ca7dfo0;nat=yes;vsf=dTRjN2NvOSh5O2l3chRUKWUpZWo5MGkrLFxGBRldBw-->. Via: SIP/2.0/UDP 77.246.81.132;branch=z9hG4bK821.3a570854.0. Via: SIP/2.0/UDP 192.168.0.113:5060;rport=8680;received=77.246.81.162 ;branch=z9hG4bK-eb23842c. From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=4209e88c969ca7dfo0. To: "st2030" <sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr>>. Call-ID: 39d2f3d0-b283756b(a)192.168.0.113. CSeq: 102 INVITE. Max-Forwards: 49. Contact: "Sam" <sip:0123451010@77.246.81.162:8680>. Expires: 240. User-Agent: Linksys/SPA941-5.1.8. Content-Length: 281. Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER. Supported: 100rel, replaces. Content-Type: application/sdp. Privacy: id. Remote-Party-ID: <<null>>;party=caller;privacy=yes;screen=no. . v=0. o=- 33629308 33629308 IN IP4 192.168.0.113. s=-. c=IN IP4 77.246.81.133. t=0 0. m=audio 35132 RTP/AVP 18 0 8 101. a=rtpmap:18 G729a/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:30. a=sendrecv. a=nortpproxy:yes. U 2008/11/28 12:14:04.905612 77.246.81.162:8680 -> 77.246.81.132:5060 CANCEL sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr> SIP/2.0. Via: SIP/2.0/UDP 192.168.0.113:5060;branch=z9hG4bK-eb23842c. From: "Sam" <sip:0123451010@sip.720.fr <sip%3A0123451010(a)sip.720.fr> >;tag=4209e88c969ca7dfo0. To: "st2030" <sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr>>. Call-ID: 39d2f3d0-b283756b(a)192.168.0.113. CSeq: 102 CANCEL. Max-Forwards: 50. Proxy-Authorization: Digest username="0123451010",realm="sip.720.fr ",nonce="492fd3a300000094c9e8b4f3805f7f96dc3f36f981a64570",uri=" sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr> ",algorithm=MD5,response="07e4433c6000309b8cac1f917dbb9643",qop=auth,nc=00000002,cnonce="7c8a76fd". User-Agent: Linksys/SPA941-5.1.8. Content-Length: 0. . U 2008/11/28 12:14:04.912088 77.246.81.132:5060 -> 77.246.81.162:8680 SIP/2.0 501 Method Not Supported Here. Via: SIP/2.0/UDP 192.168.0.113:5060 ;branch=z9hG4bK-eb23842c;rport=8680;received=77.246.81.162. From: "Sam" <sip:0123451010@sip.720.fr <sip%3A0123451010(a)sip.720.fr> >;tag=4209e88c969ca7dfo0. To: "st2030" <sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr> >;tag=d25c9349df891607b66aeb00d1da49ca.b1d0. Call-ID: 39d2f3d0-b283756b(a)192.168.0.113. CSeq: 102 CANCEL. Server: 720 DEGRES SIP PROXY. Content-Length: 0. Warning: 392 77.246.81.132:5060 "Noisy feedback tells: pid=14137 req_src_ip=77.246.81.162 req_src_port=8680 in_uri=sip:0123451013@sip.720.fr<sip%3A0123451013(a)sip.720.fr>out_uri= sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr> via_cnt==1". -- Samuel MULLER Ingénieur Reseaux & Telecom 720 DEGRES +33 (0)663 128 505 sml(a)720.fr

3 6

[Kamailio-Users] Webx-SER: a new project to give kamailio users a web interface (like Serweb was)
by yannick 30 Nov '08

30 Nov '08

Hello, I started a project to give users of Kamailio server a web interface to register and manage their datas. It was inspired by a need of the Ekiga.net platform ( https://www.ekiga.net ) to allow users register like they were able to do when Ekiga.net was using SER and Serweb. I called this software Webx-SER. Webx-SER feature now: * Registration of accounts to kamailio * Password reminder * Changing password Technically, Webx-SER use PHP and MySQL. It has a cache system for common non-interactives pages, a template system to split HTML from PHP and a captcha system to prevent bots. Some work has been put in managing forms to make it user-friendly. The licence is GPL 3 or higher. Webx-SER is actually used on https://www.ekiga.net There is a web site for Webx-SER developments, including users and devels mailing-list, bug tracking system, source tarball releases and GIT repository for source code here: http://webxser.tuxfamily.org/ Feedback, comments, help in coding will be warmly welcome. I also want to thanks Damien Sandras and Jan Schampera for their help, support and inspiration. Best regards, Yannick Defais -- Me joindre en téléphonie IP / vidéoconférence ? sip:yannick@ekiga.net Logiciel de VoIP Ekiga : http://www.ekiga.org http://wiki.ekiga.org/index.php/Which_programs_work_with_Ekiga_%3F

2 3

[Kamailio-Users] Attendant call transfer between asterisk gateway and OpenSER problem
by muhammad akl 28 Nov '08

28 Nov '08

I have the following scenario : Pstn Number(1234567) <-----------> Asterisk GW <----------------> Openser | <-------------->11803 | | | <--------------> 11801 Firstly extension 11803 will call the pstn number and this works fine without no problem , after that 11803 will put 1234567 on hold and will call 11801 , then 11803 will transfer 1234567 to 11801 (<---- the problem now started ), what is happening now is that both 123456 and 11801 will be on hold with 11803 after the transfer is done I've traced the full dialog between the three extensions and found an interesting part , which a NOTIFY message came from asterisk and contains this sentence : SIP/2.0 481 Call leg/transaction does not exist The addresses of the devices as follows : Asterisk Gw : 192.168.200.202 OpenSER : 192.168.200.10 11803 : 192.168.200.222 11801 : 192.168.200.224 The full trace : http://muhammad.akl.googlepages.com/debug.txt Regards

2 2

Re: [Kamailio-Users] Trying to deliver a call across multiple peers with t_relay
by Tyler Brauer 28 Nov '08

28 Nov '08

Thank you Klaus for the suggestions. I've implemented the configuration below. When the first t_relay fails, Kamailio generates the 408 Request Timeout and doesn't attempt to try an INVITE to the second address. This what the syslog says: Nov 28 06:11:13 server kamailio[1315]: Attempting Carrier 1 Nov 28 06:11:28 server kamailio[1323]: Attempting Carrier 2 Nov 28 06:11:28 server kamailio[1323]: ERROR:tm:t_forward_nonack: no branch for forwarding Nov 28 06:11:28 server kamailio[1323]: ERROR:tm:w_t_relay: t_forward_nonack failed Nov 28 06:11:28 server kamailio[1317]: Attempting Carrier 1 And here's the watered-down version of my configuration. # - - - - - - - - - - - - - - - - - - - - route[0] { if($si=='10.10.10.10') { # Allowed Host route(1); } else { sl_send_reply("603", "Decline"); exit; } } # - - - - - - - - - - - - - - - - - - - - route[1] { if(msg:len > 2048) { sl_send_reply("513", "Message Too Big"); exit; } if (!mf_process_maxfwd_header("10")) { sl_send_reply("483", "Too Many Hops"); exit; } if (method==OPTIONS) { if ((uri==myself) && (! uri=~"sip:.*[@]+.*")) { options_reply(); exit; } } if (!method=="REGISTER") { record_route(); } if (loose_route()) { append_hf("P-hint: rr-enforced\r\n"); } if (is_method("CANCEL")) { if (t_check_trans()) { t_relay(); } exit; } route(2); } # - - - - - - - - - - - - - - - - - - - - route[2] { xlog("L_INFO", "Attempting Carrier 1"); t_on_failure("3"); t_relay("udp:1.1.1.1:5090","0x2"); exit; } # - - - - - - - - - - - - - - - - - - - - failure_route[3] { xlog("L_INFO", "Attempting Carrier 2"); t_on_failure("4"); t_relay("udp:2.2.2.2:5060"); exit; } # - - - - - - - - - - - - - - - - - - - - failure_route[4] { # I would like to know how to redirect the # original call destined to extension "100" # to 2015551234, but the originating server # will get nervous if the username@ part # of its SIP request is changed. How could } # - - - - - - - - - - - - - - - - - - - - Any further suggestions would be appreciated. Thanks!

2 1

[Kamailio-Users] Does enum_query support wildcard and non-terminal NAPTR record ?
by jerome boileau 28 Nov '08

28 Nov '08

Hi, I'm testing an ENUM DNS server (BIND9) with Openser 1.2.0. It seems that Openser Enum module doesn't support wildcard and non terminal NAPTR record. Enum module is working well when the NAPTR record is defined in the ENUM DNS with complete phone number and ‘u’ flag. Here is an example of the NAPTR record: 1.2.3.4.5.6.7.8.9.3.3.enum1.net IN NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:+33987654321@example.com!". When I declared a wildcard in the ENUM DNS (ie: *.enum1.net IN NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:+33987654321@example.com!".), enum_query function didn't find the NAPTR record. The following message is returned in the log, enum_query(): No NAPTR record found for 1.2.3.4.5.6.7.8.9.3.3.enum1.net. Should resolver (ie resolve.c source file) or enum module be modified to handle wildcard or is it just a parameter to set ? In case of wildcard CNAME record instead of NAPTR, openser behave in the same way, the CNAME record was not found. I also tried to use a non-terminal NAPTR to forward the ENUM DNS query towards another domain. Here is the NAPTR record declared in the ENUM DNS: 1.2.3.4.5.6.7.8.9.3.3.enum1.net IN NAPTR 10 100 "" "" "!^.*([0-9]{11})$!\\1.enum2.net!". By using sip_match function, the enum_query (ie do_query) function discards the NAPTR record without ‘u’ flag. I removed the check on the flag (comment sip_match function) so the NAPTR record is not discarded. But instead of looking for the terminal NATR record, enum_query function overwrites the Request URI with the non-terminal NAPTR record. Is the handling of non terminal NAPTR fixed in a new version of enum module ? If not, is it planned ? Thanks in advance for your help. Best regards, Jérôme -- View this message in context: http://www.nabble.com/Does-enum_query-support-wildcard-and-non-terminal-NAP… Sent from the OpenSER Users Mailing List mailing list archive at Nabble.com.

3 3

[Kamailio-Users] simultaneus calls limitations
by BERGANZ François 28 Nov '08

28 Nov '08

Hello all, How can I contrôle « simultaneus calls limitation I could try to add in the database the number off simultaneous calls per user and when I check invite+1 cancel-1 bye-1 busy-1 BUT I have to insert in the database for each calls the call-id to know which user to do +1 or -1 Have you another idea? Thank you Cordialement, BERGANZ François P Pensez à l'Environnement, n'imprimez ce mail que si nécessaire.

2 1

[Kamailio-Users] How to add Retry-After header in 503 response
by Alex Hermann 28 Nov '08

28 Nov '08

Hello, is there a way to add a Retry-After header to a 503 response i'm sending out using t_reply? Use case: t_relay creates an internal 408 on timeout. From failure-route, i want to pass it upstream as 503 with retry-after header. Changing the reply to 503 using t_reply works, but how to add the header? The reply obviously doens't pass through any reply_route. -- Greetings, Alex Hermann

3 4

[Kamailio-Users] Trying to deliver a call across multiple peers with t_relay
by Tyler Brauer 28 Nov '08

28 Nov '08

Good morning/afternoon/evening! I'm trying to accomplish two things. * First, I'd like to try sending a call from our B2BUA through Kamailio to one of our SIP peers, but in the event that the peer is unreachable, try the same call across an alternate peer. I'm currently trying something in our routing block like this. if(!t_relay("udp:1.1.1.1:5060","0x2")) { if(!t_relay("udp:2.2.2.2:5060")) { xlog("L_INFO", "Could not complete"); } } I've also been trying to put together something similar using t_on_failure(#) and a failure_route[#] block to say "if the first t_relay fails, try this instead". In both instances, when fr_timer elapses because the first peer hasn't responded to an INVITE, I can't stop Kamailio from throwing a "SIP/2.0 408 Request Timeout" back to the B2BUA. I have tried setting the flag on t_relay to keep quiet in the event of a forward failure, and instead use something like sl_send_reply("181", "Call Is Being Forwarded") to say to the agent "hold on, we're still trying". I can't seem to find the syntax to make any of that work. The 408 still keeps getting delivered (in spite of the flag on t_relay) to our server, which causes it to stop trying to deliver the call through Kamailio. * The second thing I'd like is that if the first two peers are unavailable, the request is rewritten to go across a third peer as a PSTN call. (eg: a call tries to reach 101(a)1.1.1.1 fails, then 101(a)2.2.2.2 fails, so then 2015551234(a)3.3.3.3 is tried). This requires rewriting the username field of the request URI, but I'm not sure how to do that without confusing the originating server. Could anyone help with the config syntax to resolve either of those two problems? Thank you very much!

3 2

[Kamailio-Users] important: pseudo-variables moved from core to pv module
by Elena-Ramona Modroiu 27 Nov '08

27 Nov '08

Hi, all pseudo-variables exported by core in the past are now in PV module. Therefore if you use any of them in your config you have to load the PV module. This is valid with devel version (trunk). This change was discussed some time ago on devel mailing list, the core is slimmer now. Soon transformations will be moved as well, making possible to export new transformations from modules. The core will include only the API to export PV and transformations, plus the engine to use them in config file. Regards, Ramona

3 2

[Serusers] Registering port instead of contact field port
by Daniel Serrano 27 Nov '08

27 Nov '08

Dear all, I am using SER as IM server and I found that the SER use the contact field to storage the user's location in the memory for future requests. I noted this using the command "serctl alias show" and checking some traces. Since I'm using a NAT scenario I'd like to use the UDP port that my SER server receives during the registration instead of the contact field port to reach the users after their registration. Is there any way to do this? Thanks in advanced. * Daniel Serrano D.** *

2 1

[Kamailio-Users] WARNING dbrow2info: non-local socket
by ALAEDDINE abbech 27 Nov '08

27 Nov '08

Hi, maybe this has been discussed before and maybe I'm not too good in reading mailinglists, but anyhow. If you have two OpenSER proxies storing to the same location table. I see in my logs: WARNING:usrloc:dbrow2info: non-local socket @of other server:5060 ...ignoring, I have a probleme with my DB when i register some UA. This is crucial? If this is not crucial, might this message be supressed in some way? Thanks,

2 3

Re: [Kamailio-Users] method value of the CSeq field
by Alex Balashov 27 Nov '08

27 Nov '08

Iñaki Baz Castillo wrote: > El Miércoles, 26 de Noviembre de 2008, Alex Balashov escribió: >> Iñaki Baz Castillo wrote: >>> El Miércoles, 26 de Noviembre de 2008, Alex Balashov escribió: >>>> You can parse it yourself using textops from $hdr(CSeq). >>> Not needed at all, just read $rm variable (works for requests and >>> responses). >> I didn't say it was needed, just that it could be done. ;) $rm is >> definitely best. > > I agree with you, parsing $hdr(CSeq) is cooler XD > In about the same measure that #include <stdio.h> #include <stdlib.h> int main(void) { FILE *fp = fopen("/dev/stdout", "w"); fprintf(fp, "Hello World!\n"); fclose(fp); return EXIT_SUCCESS; } is cooler than 10 PRINT "HELLO WORLD" 20 END :) -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599

2 1

[Kamailio-Users] http_query function
by jh＠tutpro.com 27 Nov '08

27 Nov '08

--text follows this line-- i wrote a http_query function that allows kamailio to make an http request and get access to parts of the reply. see trunk/modules/utils/README for details. -- juha

7 19

[Kamailio-Users] attendant call transfer between asterisk gateway and OpenSER problem
by muhammad akl 27 Nov '08

27 Nov '08

I have the following scenario : Pstn Number(1234567) <-----------> Asterisk GW <----------------> Openser | <-------------->11803 | | | <--------------> 11801 Firstly extension 11803 will call the pstn number and this works fine without no problem , after that 11803 will put 1234567 on hold and will call 11801 , then 11803 will transfer 1234567 to 11801 (<---- the problem now started ), what is happening now is that both 123456 and 11801 will be on hold with 11803 after the transfer is done I've traced the full dialog between the three extensions and found an interesting part , which a NOTIFY message came from asterisk and contains this sentence : SIP/2.0 481 Call leg/transaction does not exist The addresses of the devices as follows : Asterisk Gw : 192.168.200.202 OpenSER : 192.168.200.10 11803 : 192.168.200.222 11801 : 192.168.200.224 The full trace is below : interface: nge1 (192.168.200.0/255.255.255.0) filter: (ip) and ( port 5060 ) # U 192.168.200.222:5060 -> 192.168.200.10:5060 INVITE sip:1234567@192.168.200.10:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T1DC2F22B. Session-Expires: 1800. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372869 INVITE. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 70. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. User-Agent: DPH-14001.01. Content-Type: application/sdp. Content-Length: 242. . v=0. o=11803 273718813 273718813 IN IP4 192.168.200.222. s=DPH-14001.01. c=IN IP4 192.168.200.222. t=0 0. m=audio 41000 RTP/AVP 0 18 4. a=rtpmap:0 PCMU/8000/1. a=rtpmap:18 G729/8000/1. a=fmtp:18 annexb=no. a=rtpmap:4 G723/8000/1. a=sendrecv. 8 # U 192.168.200.10:5060 -> 192.168.200.222:5060 SIP/2.0 407 Proxy Authentication Required. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T1DC2F22B. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060 >;tag=5be75dc65ffa8fb5a76b533c12178918.d1e1. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372869 INVITE. Proxy-Authenticate: Digest realm="192.168.200.10", nonce="492cf863ac436e9c37697617b6c5e4491e58df17". Server: OpenSER (1.3.3-notls (i386/solaris)). Content-Length: 0. . # U 192.168.200.222:5060 -> 192.168.200.10:5060 ACK sip:1234567@192.168.200.10:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T1DC2F22B. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060 >;tag=5be75dc65ffa8fb5a76b533c12178918.d1e1. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372869 ACK. User-Agent: DPH-14001.01. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 70. Content-Length: 0. . # U 192.168.200.222:5060 -> 192.168.200.10:5060 INVITE sip:1234567@192.168.200.10:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T3F0957F2. Session-Expires: 1800. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372870 INVITE. Proxy-Authorization: Digest username="11803", realm="192.168.200.10", nonce="492cf863ac436e9c37697617b6c5e4491e58df17", opaque="", uri=" sip:1234567@192.168.200.10:5060", response="fefb838d12f5d716f5e1789a2a36ed93". Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 70. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. User-Agent: DPH-14001.01. Content-Type: application/sdp. Content-Length: 242. . v=0. o=11803 273718813 273718813 IN IP4 192.168.200.222. s=DPH-14001.01. c=IN IP4 192.168.200.222. t=0 0. m=audio 41000 RTP/AVP 0 18 4. a=rtpmap:0 PCMU/8000/1. a=rtpmap:18 G729/8000/1. a=fmtp:18 annexb=no. a=rtpmap:4 G723/8000/1. a=sendrecv. _ # U 192.168.200.10:5060 -> 192.168.200.222:5060 SIP/2.0 100 Giving a try. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T3F0957F2. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372870 INVITE. Server: OpenSER (1.3.3-notls (i386/solaris)). Content-Length: 0. . # U 192.168.200.10:5060 -> 192.168.200.202:5060 INVITE sip:1234567@192.168.200.202:5060 SIP/2.0. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK596c.3851.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T3F0957F2. Session-Expires: 1800. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372870 INVITE. Proxy-Authorization: Digest username="11803", realm="192.168.200.10", nonce="492cf863ac436e9c37697617b6c5e4491e58df17", opaque="", uri=" sip:1234567@192.168.200.10:5060", response="fefb838d12f5d716f5e1789a2a36ed93". Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 69. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. User-Agent: DPH-14001.01. Content-Type: application/sdp. Content-Length: 242. . v=0. o=11803 273718813 273718813 IN IP4 192.168.200.222. s=DPH-14001.01. c=IN IP4 192.168.200.222. t=0 0. m=audio 41000 RTP/AVP 0 18 4. a=rtpmap:0 PCMU/8000/1. a=rtpmap:18 G729/8000/1. a=fmtp:18 annexb=no. a=rtpmap:4 G723/8000/1. a=sendrecv. # U 192.168.200.202:5060 -> 192.168.200.10:5060 SIP/2.0 100 Trying. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK596c.3851.0;received= 192.168.200.10. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T3F0957F2. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372870 INVITE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Contact: <sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202>>. Content-Length: 0. . U 192.168.200.202:5060 -> 192.168.200.10:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK596c.3851.0;received= 192.168.200.10. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T3F0957F2. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372870 INVITE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Contact: <sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202>>. Content-Type: application/sdp. Content-Length: 235. . v=0. o=root 2712 2712 IN IP4 192.168.200.202. s=session. c=IN IP4 192.168.200.202. t=0 0. m=audio 19872 RTP/AVP 0 18. a=rtpmap:0 PCMU/8000. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=silenceSupp:off - - - -. a=ptime:20. a=sendrecv. # U 192.168.200.10:5060 -> 192.168.200.222:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T3F0957F2. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372870 INVITE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Contact: <sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202>>. Content-Type: application/sdp. Content-Length: 235. . v=0. o=root 2712 2712 IN IP4 192.168.200.202. s=session. c=IN IP4 192.168.200.202. t=0 0. m=audio 19872 RTP/AVP 0 18. a=rtpmap:0 PCMU/8000. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=silenceSupp:off - - - -. a=ptime:20. a=sendrecv. # U 192.168.200.222:5060 -> 192.168.200.10:5060 ACK sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202> SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T2A279063. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372870 ACK. User-Agent: DPH-14001.01. Contact: <sip:11803@192.168.200.222:5060>. Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. Max-Forwards: 70. Content-Length: 0. . # U 192.168.200.10:5060 -> 192.168.200.202:5060 ACK sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202> SIP/2.0. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK596c.3851.2. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T2A279063. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372870 ACK. User-Agent: DPH-14001.01. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 69. Content-Length: 0. . U 192.168.200.222:5060 -> 192.168.200.10:5060 INVITE sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202> SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T6F622AB5. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372871 INVITE. Contact: <sip:11803@192.168.200.222:5060>. Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. Max-Forwards: 70. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. User-Agent: DPH-14001.01. Content-Type: application/sdp. Content-Length: 234. . v=0. o=11803 273718813 273718814 IN IP4 192.168.200.222. s=DPH-14001.01. c=IN IP4 0.0.0.0. t=0 0. m=audio 41000 RTP/AVP 0 18 4. a=rtpmap:0 PCMU/8000/1. a=rtpmap:18 G729/8000/1. a=fmtp:18 annexb=no. a=rtpmap:4 G723/8000/1. a=sendonly. # U 192.168.200.10:5060 -> 192.168.200.222:5060 SIP/2.0 100 Giving a try. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T6F622AB5. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372871 INVITE. Server: OpenSER (1.3.3-notls (i386/solaris)). Content-Length: 0. . # U 192.168.200.10:5060 -> 192.168.200.202:5060 INVITE sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202> SIP/2.0. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK696c.5c64.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T6F622AB5. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372871 INVITE. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 69. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. User-Agent: DPH-14001.01. Content-Type: application/sdp. Content-Length: 234. . v=0. o=11803 273718813 273718814 IN IP4 192.168.200.222. s=DPH-14001.01. c=IN IP4 0.0.0.0. t=0 0. m=audio 41000 RTP/AVP 0 18 4. a=rtpmap:0 PCMU/8000/1. a=rtpmap:18 G729/8000/1. a=fmtp:18 annexb=no. a=rtpmap:4 G723/8000/1. a=sendonly. # U 192.168.200.202:5060 -> 192.168.200.10:5060 SIP/2.0 100 Trying. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK696c.5c64.0;received= 192.168.200.10. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T6F622AB5. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372871 INVITE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Contact: <sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202>>. Content-Length: 0. . # U 192.168.200.202:5060 -> 192.168.200.10:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK696c.5c64.0;received= 192.168.200.10. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T6F622AB5. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372871 INVITE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Contact: <sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202>>. Content-Type: application/sdp. Content-Length: 235. . v=0. o=root 2712 2713 IN IP4 192.168.200.202. s=session. c=IN IP4 192.168.200.202. t=0 0. m=audio 19872 RTP/AVP 0 18. a=rtpmap:0 PCMU/8000. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=silenceSupp:off - - - -. a=ptime:20. a=recvonly. # U 192.168.200.10:5060 -> 192.168.200.222:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T6F622AB5. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372871 INVITE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Contact: <sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202>>. Content-Type: application/sdp. Content-Length: 235. . v=0. o=root 2712 2713 IN IP4 192.168.200.202. s=session. c=IN IP4 192.168.200.202. t=0 0. m=audio 19872 RTP/AVP 0 18. a=rtpmap:0 PCMU/8000. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=silenceSupp:off - - - -. a=ptime:20. a=recvonly. # U 192.168.200.222:5060 -> 192.168.200.10:5060 ACK sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202> SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T555ECDF6. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372871 ACK. User-Agent: DPH-14001.01. Contact: <sip:11803@192.168.200.222:5060>. Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. Max-Forwards: 70. Content-Length: 0. . # U 192.168.200.10:5060 -> 192.168.200.202:5060 ACK sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202> SIP/2.0. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK696c.5c64.2. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T555ECDF6. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372871 ACK. User-Agent: DPH-14001.01. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 69. Content-Length: 0. . # U 192.168.200.222:5060 -> 192.168.200.10:5060 INVITE sip:11801@192.168.200.10:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T584FCDF0. Session-Expires: 1800. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 612491577 INVITE. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 70. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. User-Agent: DPH-14001.01. Content-Type: application/sdp. Content-Length: 242. . v=0. o=11803 273772573 273772573 IN IP4 192.168.200.222. s=DPH-14001.01. c=IN IP4 192.168.200.222. t=0 0. m=audio 41000 RTP/AVP 0 18 4. a=rtpmap:0 PCMU/8000/1. a=rtpmap:18 G729/8000/1. a=fmtp:18 annexb=no. a=rtpmap:4 G723/8000/1. a=sendrecv. # U 192.168.200.10:5060 -> 192.168.200.222:5060 SIP/2.0 407 Proxy Authentication Required. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T584FCDF0. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060 >;tag=5be75dc65ffa8fb5a76b533c12178918.146b. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 612491577 INVITE. Proxy-Authenticate: Digest realm="192.168.200.10", nonce="492cf87251a238af089dfab6b5d7f8c274907ba8". Server: OpenSER (1.3.3-notls (i386/solaris)). Content-Length: 0. . # U 192.168.200.222:5060 -> 192.168.200.10:5060 ACK sip:11801@192.168.200.10:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T584FCDF0. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060 >;tag=5be75dc65ffa8fb5a76b533c12178918.146b. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 612491577 ACK. User-Agent: DPH-14001.01. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 70. Content-Length: 0. . 2 # U 192.168.200.222:5060 -> 192.168.200.10:5060 INVITE sip:11801@192.168.200.10:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T51E2E9FC. Session-Expires: 1800. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 612491578 INVITE. Proxy-Authorization: Digest username="11803", realm="192.168.200.10", nonce="492cf87251a238af089dfab6b5d7f8c274907ba8", opaque="", uri=" sip:11801@192.168.200.10:5060", response="c182454ce412ce07dd2a0d13c416bf58". Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 70. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. User-Agent: DPH-14001.01. Content-Type: application/sdp. Content-Length: 242. . v=0. o=11803 273772573 273772573 IN IP4 192.168.200.222. s=DPH-14001.01. c=IN IP4 192.168.200.222. t=0 0. m=audio 41000 RTP/AVP 0 18 4. a=rtpmap:0 PCMU/8000/1. a=rtpmap:18 G729/8000/1. a=fmtp:18 annexb=no. a=rtpmap:4 G723/8000/1. a=sendrecv. b # U 192.168.200.10:5060 -> 192.168.200.222:5060 SIP/2.0 100 Giving a try. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T51E2E9FC. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 612491578 INVITE. Server: OpenSER (1.3.3-notls (i386/solaris)). Content-Length: 0. . # U 192.168.200.10:5060 -> 192.168.200.224:5060 INVITE sip:11801@192.168.200.224:5060 SIP/2.0. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T408052446>. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bKa2ce.3cf7.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T51E2E9FC. Session-Expires: 1800. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 612491578 INVITE. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 69. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. User-Agent: DPH-14001.01. Content-Type: application/sdp. Content-Length: 242. . v=0. o=11803 273772573 273772573 IN IP4 192.168.200.222. s=DPH-14001.01. c=IN IP4 192.168.200.222. t=0 0. m=audio 41000 RTP/AVP 0 18 4. a=rtpmap:0 PCMU/8000/1. a=rtpmap:18 G729/8000/1. a=fmtp:18 annexb=no. a=rtpmap:4 G723/8000/1. a=sendrecv. # U 192.168.200.224:5060 -> 192.168.200.10:5060 SIP/2.0 100 Trying. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bKa2ce.3cf7.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T51E2E9FC. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. Contact: <sip:11801@192.168.200.224:5060>. CSeq: 612491578 INVITE. User-Agent: DPH-14001.01. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Content-Length: 0. . # U 192.168.200.224:5060 -> 192.168.200.10:5060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bKa2ce.3cf7.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T51E2E9FC. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. Contact: <sip:11801@192.168.200.224:5060>. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T408052446>. CSeq: 612491578 INVITE. User-Agent: DPH-14001.01. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Content-Length: 0. . 0 # U 192.168.200.10:5060 -> 192.168.200.222:5060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T51E2E9FC. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. Contact: <sip:11801@192.168.200.224:5060>. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T408052446>. CSeq: 612491578 INVITE. User-Agent: DPH-14001.01. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Content-Length: 0. . # U 192.168.200.224:5060 -> 192.168.200.10:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bKa2ce.3cf7.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T51E2E9FC. Require: timer. Session-Expires: 1800;refresher=uac. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. Contact: <sip:11801@192.168.200.224:5060>. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T408052446>. CSeq: 612491578 INVITE. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. Content-Type: application/sdp. Content-Length: 167. . v=0. o=11801 276818065 276818065 IN IP4 192.168.200.224. s=DPH-14001.01. c=IN IP4 192.168.200.224. t=0 0. m=audio 41000 RTP/AVP 0. a=rtpmap:0 PCMU/8000/1. a=sendrecv. # U 192.168.200.10:5060 -> 192.168.200.222:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T51E2E9FC. Require: timer. Session-Expires: 1800;refresher=uac. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. Contact: <sip:11801@192.168.200.224:5060>. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T408052446>. CSeq: 612491578 INVITE. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. Content-Type: application/sdp. Content-Length: 167. . v=0. o=11801 276818065 276818065 IN IP4 192.168.200.224. s=DPH-14001.01. c=IN IP4 192.168.200.224. t=0 0. m=audio 41000 RTP/AVP 0. a=rtpmap:0 PCMU/8000/1. a=sendrecv. # U 192.168.200.222:5060 -> 192.168.200.10:5060 ACK sip:11801@192.168.200.224:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T3C593173. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 612491578 ACK. User-Agent: DPH-14001.01. Contact: <sip:11803@192.168.200.222:5060>. Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T408052446>. Max-Forwards: 70. Content-Length: 0. . 0 # U 192.168.200.10:5060 -> 192.168.200.224:5060 ACK sip:11801@192.168.200.224:5060 SIP/2.0. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T408052446>. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bKa2ce.3cf7.2. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T3C593173. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 612491578 ACK. User-Agent: DPH-14001.01. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 69. Content-Length: 0. . # U 192.168.200.222:5060 -> 192.168.200.10:5060 INVITE sip:11801@192.168.200.224:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T1280D8E9. Session-Expires: 1800;refresher=uac. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 612491579 INVITE. Contact: <sip:11803@192.168.200.222:5060>. Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T408052446>. Max-Forwards: 70. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. User-Agent: DPH-14001.01. Content-Type: application/sdp. Content-Length: 234. . v=0. o=11803 273772573 273772574 IN IP4 192.168.200.222. s=DPH-14001.01. c=IN IP4 0.0.0.0. t=0 0. m=audio 41000 RTP/AVP 0 18 4. a=rtpmap:0 PCMU/8000/1. a=rtpmap:18 G729/8000/1. a=fmtp:18 annexb=no. a=rtpmap:4 G723/8000/1. a=sendonly. # U 192.168.200.10:5060 -> 192.168.200.222:5060 SIP/2.0 100 Giving a try. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T1280D8E9. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 612491579 INVITE. Server: OpenSER (1.3.3-notls (i386/solaris)). Content-Length: 0. . # U 192.168.200.10:5060 -> 192.168.200.224:5060 INVITE sip:11801@192.168.200.224:5060 SIP/2.0. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T408052446>. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK92ce.5361.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T1280D8E9. Session-Expires: 1800;refresher=uac. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 612491579 INVITE. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 69. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. User-Agent: DPH-14001.01. Content-Type: application/sdp. Content-Length: 234. . v=0. o=11803 273772573 273772574 IN IP4 192.168.200.222. s=DPH-14001.01. c=IN IP4 0.0.0.0. t=0 0. m=audio 41000 RTP/AVP 0 18 4. a=rtpmap:0 PCMU/8000/1. a=rtpmap:18 G729/8000/1. a=fmtp:18 annexb=no. a=rtpmap:4 G723/8000/1. a=sendonly. # U 192.168.200.224:5060 -> 192.168.200.10:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK92ce.5361.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T1280D8E9. Require: timer. Session-Expires: 1800;refresher=uac. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. Contact: <sip:11801@192.168.200.224:5060>. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T408052446>. CSeq: 612491579 INVITE. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. Content-Type: application/sdp. Content-Length: 167. . v=0. o=11801 276818065 276818065 IN IP4 192.168.200.224. s=DPH-14001.01. c=IN IP4 192.168.200.224. t=0 0. m=audio 41000 RTP/AVP 0. a=rtpmap:0 PCMU/8000/1. a=recvonly. # U 192.168.200.10:5060 -> 192.168.200.222:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T1280D8E9. Require: timer. Session-Expires: 1800;refresher=uac. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. Contact: <sip:11801@192.168.200.224:5060>. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T408052446>. CSeq: 612491579 INVITE. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. Content-Type: application/sdp. Content-Length: 167. . v=0. o=11801 276818065 276818065 IN IP4 192.168.200.224. s=DPH-14001.01. c=IN IP4 192.168.200.224. t=0 0. m=audio 41000 RTP/AVP 0. a=rtpmap:0 PCMU/8000/1. a=recvonly. # U 192.168.200.222:5060 -> 192.168.200.10:5060 ACK sip:11801@192.168.200.224:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T72B9563C. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 612491579 ACK. User-Agent: DPH-14001.01. Contact: <sip:11803@192.168.200.222:5060>. Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T408052446>. Max-Forwards: 70. Content-Length: 0. . 1 # U 192.168.200.10:5060 -> 192.168.200.224:5060 ACK sip:11801@192.168.200.224:5060 SIP/2.0. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T408052446>. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK92ce.5361.2. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T72B9563C. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 612491579 ACK. User-Agent: DPH-14001.01. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 69. Content-Length: 0. . # U 192.168.200.222:5060 -> 192.168.200.10:5060 REFER sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202> SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T218F1384. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372872 REFER. Refer-To: < sip:11801@192.168.200.10:5060?Replaces=CALL_ID21_0015E9A0D90F_T1842345680%40192.168.200.222%3Bto-tag%3D0015E970817D_T1147221029%3Bfrom-tag%3D0015E9A0D90F_T408052446 >. Referred-by: <sip:11803@192.168.200.10 <sip%3A11803(a)192.168.200.10>>. Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 70. Content-Length: 0. . P # U 192.168.200.10:5060 -> 192.168.200.202:5060 REFER sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202> SIP/2.0. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK396c.8f11.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T218F1384. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372872 REFER. Refer-To: < sip:11801@192.168.200.10:5060?Replaces=CALL_ID21_0015E9A0D90F_T1842345680%40192.168.200.222%3Bto-tag%3D0015E970817D_T1147221029%3Bfrom-tag%3D0015E9A0D90F_T408052446 >. Referred-by: <sip:11803@192.168.200.10 <sip%3A11803(a)192.168.200.10>>. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 69. Content-Length: 0. . # U 192.168.200.202:5060 -> 192.168.200.10:5060 SIP/2.0 202 Accepted. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK396c.8f11.0;received= 192.168.200.10. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T218F1384. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372872 REFER. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Contact: <sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202>>. Content-Length: 0. . # U 192.168.200.10:5060 -> 192.168.200.222:5060 SIP/2.0 202 Accepted. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T218F1384. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372872 REFER. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Contact: <sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202>>. Content-Length: 0. . # U 192.168.200.202:5060 -> 192.168.200.10:5060 NOTIFY sip:11803@192.168.200.222:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.200.202:5060;branch=z9hG4bK511c6a05;rport. Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. From: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. To: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. Contact: <sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202>>. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 102 NOTIFY. User-Agent: Asterisk PBX. Max-Forwards: 70. Event: refer;id=1844372872. Subscription-state: terminated;reason=noresource. Content-Type: message/sipfrag;version=2.0. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Content-Length: 49. . SIP/2.0 481 Call leg/transaction does not exist. # U 192.168.200.10:5060 -> 192.168.200.222:5060 NOTIFY sip:11803@192.168.200.222:5060 SIP/2.0. Record-Route: <sip:192.168.200.10;lr=on;ftag=as17b63c65>. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK3dbb.fc91.0. Via: SIP/2.0/UDP 192.168.200.202:5060;branch=z9hG4bK511c6a05;rport=5060. From: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. To: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. Contact: <sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202>>. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 102 NOTIFY. User-Agent: Asterisk PBX. Max-Forwards: 69. Event: refer;id=1844372872. Subscription-state: terminated;reason=noresource. Content-Type: message/sipfrag;version=2.0. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Content-Length: 49. . SIP/2.0 481 Call leg/transaction does not exist. # U 192.168.200.222:5060 -> 192.168.200.10:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK3dbb.fc91.0. Via: SIP/2.0/UDP 192.168.200.202:5060;branch=z9hG4bK511c6a05;rport=5060. From: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. To: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 102 NOTIFY. User-Agent: DPH-14001.01. Content-Length: 0. . 6 # U 192.168.200.10:5060 -> 192.168.200.202:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.202:5060;branch=z9hG4bK511c6a05;rport=5060. From: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. To: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 102 NOTIFY. User-Agent: DPH-14001.01. Content-Length: 0. . # U 192.168.200.201:26114 -> 192.168.200.10:5060 . . .............. # U 192.168.200.101:5060 -> 192.168.200.10:5060 .................. # U 192.168.200.224:5060 -> 192.168.200.10:5060 BYE sip:11803@192.168.200.222:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.200.224:5060;branch=z9hG4bK_0015E970817D_T7AFA8E38. From: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. To: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 1461395436 BYE. User-Agent: DPH-14001.01. Contact: <sip:11801@192.168.200.224:5060>. Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T408052446>. Max-Forwards: 70. Content-Length: 0. . # U 192.168.200.10:5060 -> 192.168.200.222:5060 BYE sip:11803@192.168.200.222:5060 SIP/2.0. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E970817D_T1147221029>. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bKd255.f616.0. Via: SIP/2.0/UDP 192.168.200.224:5060;branch=z9hG4bK_0015E970817D_T7AFA8E38. From: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. To: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 1461395436 BYE. User-Agent: DPH-14001.01. Contact: <sip:11801@192.168.200.224:5060>. Max-Forwards: 69. Content-Length: 0. . # U 192.168.200.222:5060 -> 192.168.200.10:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bKd255.f616.0. Via: SIP/2.0/UDP 192.168.200.224:5060;branch=z9hG4bK_0015E970817D_T7AFA8E38. From: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. To: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 1461395436 BYE. User-Agent: DPH-14001.01. Content-Length: 0. . # U 192.168.200.10:5060 -> 192.168.200.224:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.224:5060;branch=z9hG4bK_0015E970817D_T7AFA8E38. From: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. To: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 1461395436 BYE. User-Agent: DPH-14001.01. Content-Length: 0. . # U 192.168.200.222:5060 -> 192.168.200.10:5060 INVITE sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202> SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T5152F022. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372873 INVITE. Contact: <sip:11803@192.168.200.222:5060>. Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. Max-Forwards: 70. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. User-Agent: DPH-14001.01. Content-Type: application/sdp. Content-Length: 242. . v=0. o=11803 273718813 273718815 IN IP4 192.168.200.222. s=DPH-14001.01. c=IN IP4 192.168.200.222. t=0 0. m=audio 41000 RTP/AVP 0 18 4. a=rtpmap:0 PCMU/8000/1. a=rtpmap:18 G729/8000/1. a=fmtp:18 annexb=no. a=rtpmap:4 G723/8000/1. a=sendrecv. # U 192.168.200.10:5060 -> 192.168.200.222:5060 SIP/2.0 100 Giving a try. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T5152F022. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372873 INVITE. Server: OpenSER (1.3.3-notls (i386/solaris)). Content-Length: 0. . # U 192.168.200.10:5060 -> 192.168.200.202:5060 INVITE sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202> SIP/2.0. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK496c.a647.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T5152F022. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372873 INVITE. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 69. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. User-Agent: DPH-14001.01. Content-Type: application/sdp. Content-Length: 242. . v=0. o=11803 273718813 273718815 IN IP4 192.168.200.222. s=DPH-14001.01. c=IN IP4 192.168.200.222. t=0 0. m=audio 41000 RTP/AVP 0 18 4. a=rtpmap:0 PCMU/8000/1. a=rtpmap:18 G729/8000/1. a=fmtp:18 annexb=no. a=rtpmap:4 G723/8000/1. a=sendrecv. # U 192.168.200.202:5060 -> 192.168.200.10:5060 SIP/2.0 100 Trying. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK496c.a647.0;received= 192.168.200.10. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T5152F022. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372873 INVITE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Contact: <sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202>>. Content-Length: 0. . # U 192.168.200.202:5060 -> 192.168.200.10:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK496c.a647.0;received= 192.168.200.10. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T5152F022. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372873 INVITE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Contact: <sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202>>. Content-Type: application/sdp. Content-Length: 235. . v=0. o=root 2712 2714 IN IP4 192.168.200.202. s=session. c=IN IP4 192.168.200.202. t=0 0. m=audio 19872 RTP/AVP 0 18. a=rtpmap:0 PCMU/8000. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=silenceSupp:off - - - -. a=ptime:20. a=sendrecv. # U 192.168.200.10:5060 -> 192.168.200.222:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T5152F022. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372873 INVITE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Contact: <sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202>>. Content-Type: application/sdp. Content-Length: 235. . v=0. o=root 2712 2714 IN IP4 192.168.200.202. s=session. c=IN IP4 192.168.200.202. t=0 0. m=audio 19872 RTP/AVP 0 18. a=rtpmap:0 PCMU/8000. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=silenceSupp:off - - - -. a=ptime:20. a=sendrecv. # U 192.168.200.222:5060 -> 192.168.200.10:5060 ACK sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202> SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T36B8312B. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372873 ACK. User-Agent: DPH-14001.01. Contact: <sip:11803@192.168.200.222:5060>. Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. Max-Forwards: 70. Content-Length: 0. . # U 192.168.200.10:5060 -> 192.168.200.202:5060 ACK sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202> SIP/2.0. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK496c.a647.2. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T36B8312B. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372873 ACK. User-Agent: DPH-14001.01. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 69. Content-Length: 0. . # U 192.168.200.222:5060 -> 192.168.200.10:5060 BYE sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202> SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T2506AE3F. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372874 BYE. User-Agent: DPH-14001.01. Contact: <sip:11803@192.168.200.222:5060>. Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. Max-Forwards: 70. Content-Length: 0. . # U 192.168.200.10:5060 -> 192.168.200.202:5060 BYE sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202> SIP/2.0. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK196c.a9d3.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T2506AE3F. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372874 BYE. User-Agent: DPH-14001.01. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 69. Content-Length: 0. . # U 192.168.200.202:5060 -> 192.168.200.10:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK196c.a9d3.0;received= 192.168.200.10. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T2506AE3F. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372874 BYE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Contact: <sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202>>. Content-Length: 0. . # U 192.168.200.10:5060 -> 192.168.200.222:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T2506AE3F. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372874 BYE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Contact: <sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202>>. Content-Length: 0. .

1 0

[Kamailio-Users] serMyAdmin 1.0 Beta error
by Ricky Gutierrez 26 Nov '08

26 Nov '08

Hi list, recently I had to make some modifications to the chart subscriber of my openser to be able to use the CDRTool, now when I make an user with the serMyAdmin-BETA-1.0.war it shows me an error : please they can help me with this problem? best regards rickygm Grails Runtime Exception Error Details [leonardo]Caused by: org.springframework.jdbc.UncategorizedSQLException: Hibernate operation: could not insert: [User]; uncategorized SQLException for SQL [insert into subscriber (version, password_hash, auth_username, rpid, datetime_created, domain_id, domain, email_address, first_name, ha1, ha1b, last_name, username, password, role_id, class) values (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, 'User')]; SQL state [HY000]; error code [1364]; Field 'quota' doesn't have a default value; nested exception is java.sql.SQLException: Field 'quota' doesn't have a default value Class: UserController

2 2

[Kamailio-Users] basic config
by Lens Oreste 26 Nov '08

26 Nov '08

I am trying to do a basic configuration, I need to add a couple of routes and add radius for billing. Please let me show me how

3 2

[Kamailio-Users] method value of the CSeq field
by Alex R.S.M 26 Nov '08

26 Nov '08

Hi, Is there any variable to return the method value of the CSeq field? (example: returns "ACK" for CSeq:1165 ACK) $cs returns only the "Sequence Number". Thansk, Alex R, _________________________________________________________________ Access your email online and on the go with Windows Live Hotmail. http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_access…

4 6

Re: [Kamailio-Users] UAC on ACK in reInvite
by Schober Walter 26 Nov '08

26 Nov '08

To finish the thread: I just entered below loose_route(): if (check_route_param("vsf=")) { avp_write("$hdr(Route[0])", "$avp(rr-param)"); avp_subst("$avp(rr-param)", "/^.*?(;vsf=[^>]+).*/\1/"); # $hdr(Route[0]) is not 1st header only, if multi header in one line xlog("L_INFO", ">> Stored UAC params $avp(rr-param)"); add_rr_param("$avp(rr-param)"); } > -----Original Message----- > From: Schober Walter > Sent: Wednesday, November 26, 2008 2:39 PM > To: 'Klaus Darilion' > Cc: 'users(a)lists.kamailio.org' > Subject: RE: AW: [Kamailio-Users] UAC on ACK in reInvite > > See below... > > > -----Original Message----- > > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > > Sent: Wednesday, November 26, 2008 1:21 AM > [...] > > > > This is clearly a bug in the useragent. The route set must not be > > changed with reINVITEs. Thus, according to the standard the > > Record-Route > > headers for indialog requests are not needed. Maybe you are calling > > record_route() for indialog requests and this confuses the client. > Fully agree on this. But some proxies add Record-Route, some > don't, Openser/Kamailio can configure it. > > It's not that clear in the RFC, but I see it the same way: > RFC 3261, 12.2 Request within a Dialog > ... > Requests within a dialog MAY contain Record-Route and > Contact header > fields. However, these requests do not cause the dialog's > route set > to be modified, although they may modify the remote target URI. > > 12.2.1.2 Processing the Responses > -> The only thing mentioned is that the _Target URI_ gets > refreshed by the 200 OK. > > => reInvites do not modify the routeset of any subsequent > request, neither the ACK not any other upcoming request. > > > Try removing the record_route() for indialog requests - may > then the > > buggy client remembers the original route set. > Done. Client sends ACK on reInvite directly then :-( > Counterpath is OK, Teles Voipbox not, other clients to be tested ... > > So I will have to add vsf uri param from Route to record > route in the proxy. This at least is a reason to upgrade :-) > It's done more easily with tranformations. > > Thanks for the discussion! For me it's "clearly a bug in the > UA" now, too ;-) However, let's find a workaround. > > br > Walter

1 0

[Serusers] Need help on a call forward always question
by Steven C. Blair 26 Nov '08

26 Nov '08

I am experiencing an issue with server side call forward always which I didn't see before but I now believe has always existed. Call forward always has been working. We recently switched phone manufacturers and now have the ability to offer bridged line appearance (BLA). Part of the process for offering BLA is to have the phones register with the shared attribute for a given line. When we enable this attribute server side call forward always breaks. When I say break I mean that the call forwards OK but the intermediate IP phone now rings which it never did before. Using ngrep I see that even with the old config (non-BLA setup) we had the same message flow: Invite (from PSTN gateway)-> Invite received at proxy-> Proxy responds to gateway with 200 OK-> Proxy loads forward address from mysql usr_preferences table Proxy rewrite R-URI to the forward address - avp_pushto("$ruri/username", "s:fwdaaddr"); Proxy send invite to this new address - but... Proxy also sends invite to each contact address registered to the original AOR. This should not happen but I think it was Always happening and the old phones just ignored it. Any thoughts on why and how to correct this behavior? The ser.cfg snippets involved are included below: Determine if call forward all is on: # call forward always if (avp_db_load("$ruri/username", "s:callfwdall")) { if (avp_check("s:callfwdall","eq/y/i")) { xlog("L_INFO", "\n[SER]: [%Tf] [%ci] User <%ru> has enabled Call Forward Always\n"); avp_write("$ruri", "$ocn"); - save original RURI for voicemail access if needed if (avp_db_load("$ruri/username", "s:fwdaaddr")) { avp_pushto("$ruri/username", "s:fwdaaddr"); rewritehostport("mydomain.edu"); xlog("L_INFO", "\n[SER]: [%Tf] [%ci] Calls for user <%tu> FORWARDING to <%ru>\n"); route(2); break; }; And call relaying is done by: route[2] { xlog("L_INFO", "\n[SER]: Route block #2 campus 5-digit extensions:\n\n"); xlog("L_INFO", "\n[SER]: [%Tf] [%ci] Route block #2: sending oncampus call from <%fu> to local gateway\n"); avp_write("65", "inv_timeout"); rewritehostport("my-gwy-ip-address:5060"); t_on_failure("1"); # for gwy failover t_relay(); break; }; Thanks,Steve Senior Network Engineer, Information Systems and Computing Networking and Telecommunications , Suite 221A /6228 University of Pennsylvania Voice:215-573-8396 FAX:215-898-9348

1 0

[Serusers] Call forward always question
by Steven C. Blair 26 Nov '08

26 Nov '08

I am experiencing an issue with server side call forward always which I didn't see before but I now believe has always existed. We recently switched phone manufacturers and now have the ability to offer bridged line appearance (BLA). Part of the process for offering BLA is to have the phones register with the shared attribute for a given line. When we enable this attribute server side call forward always breaks. When I say break I mean that the call forwards OK but the intermediate IP phone now rings which it never did before. Using ngrep I see that even with the old config we had the same message flow: Invite (from PSTN gateway)-> Invite received at proxy-> Proxy responds to gateway with 200 OK-> Proxy loads forward address from mysql usr_preferences table Proxy rewrite R-URI to the forward address - avp_pushto("$ruri/username", "s:fwdaaddr"); Proxy send invite to this new address - but... Proxy also sends invite to each contact address registered to the original AOR. This should not happen but I think it was Always happening and the old phones just ignored it. Any thoughts on why and how to correct this behavior? The ser.cfg snippets involved are included below: Determine if call forward all is on: # call forward always if (avp_db_load("$ruri/username", "s:callfwdall")) { if (avp_check("s:callfwdall","eq/y/i")) { xlog("L_INFO", "\n[SER]: [%Tf] [%ci] User <%ru> has enabled Call Forward Always\n"); avp_write("$ruri", "$ocn"); - save original RURI for voicemail access if needed if (avp_db_load("$ruri/username", "s:fwdaaddr")) { avp_pushto("$ruri/username", "s:fwdaaddr"); rewritehostport("mydomain.edu"); xlog("L_INFO", "\n[SER]: [%Tf] [%ci] Calls for user <%tu> FORWARDING to <%ru>\n"); route(2); break; }; And call relaying is done by: route[2] { xlog("L_INFO", "\n[SER]: Route block #2 campus 5-digit extensions:\n\n"); xlog("L_INFO", "\n[SER]: [%Tf] [%ci] Route block #2: sending oncampus call from <%fu> to local gateway\n"); avp_write("65", "inv_timeout"); rewritehostport("my-gwy-ip-address:5060"); t_on_failure("1"); # for gwy failover t_relay(); break; }; Thanks,Steve

1 0

[Kamailio-Users] Statistic in openser
by ALAEDDINE abbech 26 Nov '08

26 Nov '08

Hi, I know the commande #openserctl monitor and # openserctl fifo get_statistics all But i like have the number of INVITE / second in openser and the succeful INVITE/second. Who know any commande to have this statistic? thanks

3 2

Re: [Kamailio-Users] UAC on ACK in reInvite
by Schober Walter 26 Nov '08

26 Nov '08

See below... > -----Original Message----- > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > Sent: Wednesday, November 26, 2008 1:21 AM [...] > > This is clearly a bug in the useragent. The route set must not be > changed with reINVITEs. Thus, according to the standard the > Record-Route > headers for indialog requests are not needed. Maybe you are calling > record_route() for indialog requests and this confuses the client. Fully agree on this. But some proxies add Record-Route, some don't, Openser/Kamailio can configure it. It's not that clear in the RFC, but I see it the same way: RFC 3261, 12.2 Request within a Dialog ... Requests within a dialog MAY contain Record-Route and Contact header fields. However, these requests do not cause the dialog's route set to be modified, although they may modify the remote target URI. 12.2.1.2 Processing the Responses -> The only thing mentioned is that the _Target URI_ gets refreshed by the 200 OK. => reInvites do not modify the routeset of any subsequent request, neither the ACK not any other upcoming request. > Try removing the record_route() for indialog requests - may then the > buggy client remembers the original route set. Done. Client sends ACK on reInvite directly then :-( Counterpath is OK, Teles Voipbox not, other clients to be tested ... So I will have to add vsf uri param from Route to record route in the proxy. This at least is a reason to upgrade :-) It's done more easily with tranformations. Thanks for the discussion! For me it's "clearly a bug in the UA" now, too ;-) However, let's find a workaround. br Walter

2 1

[Kamailio-Users] avp assignment in openser 1.1
by ALAEDDINE abbech 26 Nov '08

26 Nov '08

Hi all, I have openser 1.1.0 and i can't do any change before i'm certain. can i write this code or we have an other syntaxe with version 1.1. $avp(s:PAI):= '"' + $fU + '" ' + '<sip:01010101010@192.222.115.213:5060>'; append_hf("P-Asserted-Identity: $avp(s:PAI)\r\n"); thanks

3 2

[Kamailio-Users] disply name RFC 3325
by ALAEDDINE abbech 26 Nov '08

26 Nov '08

Hi, I want to disply a number "010101010101" with use of RFC 3325 in openser. I read the RFC 3325 but i don't understand how do it. Where i put this number ? in diply name in P-Asserted-Identity, in username in P-Asserted-Identity ,in diply name in FROM or in username in FROM ?

4 5

[Kamailio-Users] replace the ' sip to' header
by BERGANZ François 26 Nov '08

26 Nov '08

Hello, I need to change the to sip header. How can I do it? Cordialement, BERGANZ François cid:image001.gif@01C8F7CD.6BC1D2C0 http://www.acropolistelecom.net <http://www.acropolistelecom.net/> P Pensez à l'Environnement, n'imprimez ce mail que si nécessaire.

3 2

[Kamailio-Users] avp assignment in openser 1.1
by ALAEDDINE abbech 26 Nov '08

26 Nov '08

Hi all, I have openser 1.1.0 and i can't do any change before i'm certain. can i write this code or we have an other syntaxe with version 1.1. $avp(s:PAI):= '"' + $fU + '" ' + '<sip:01010101010@192.222.115.213:5060>'; append_hf("P-Asserted-Identity: $avp(s:PAI)\r\n"); thanks

1 0

Re: [Kamailio-Users] UAC on ACK in reInvite
by Schober Walter 26 Nov '08

26 Nov '08

Hi Klaus! Thanks for the hint! Indeed looking into the vsf=xxx parameter a little bit closer, I found out, that on the reInvite the uac_replace() is done due to the Route: vsf=xxx Param (knew that :-), but the vsf=xxx is not added again on to the Record-Route (missed that :-). So the 2nd 200 OK doesn't contain it in the route-set anymore, thus the following ACK doesn't have it in the Route Header. Is it up to me to add it to Record-Route Header, if the Route Header contains these parameters? Shouldn't the uac_replace() do that on replacing the From again? Let's see, what I can do here. Br Walter -----Ursprüngliche Nachricht----- Von: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] Gesendet: Dienstag, 25. November 2008 18:04 An: Schober Walter Cc: users(a)lists.kamailio.org Betreff: Re: [Kamailio-Users] UAC on ACK in reInvite Hi Walter! Automatic restoring uses record route parameters to store the original from URI. Maybe there is something wrong with the RR header. I can not remember any changes in UAC module, thus I am not sure if an update will help you. regards klaus Schober Walter wrote: > Hello All! > > Tried to fix that anyhow but without success yet. Anyone who could > just tell me, if it's fixed in 1.4.something? > > Scenario: > A -> Openser 1.1.1 -> Openser 1.1.1 -> Openser 1.1.1 (UAC:normalize > From to phone number in national format) -> B > > A Invites B => all OK > A reInvites B with T.38 -> INVITE => OK > <- 200 OK => OK > -> ACK => From field not handled by UAC. > > UAC config all default, so UAC restore mode "auto". Neither INVITE nor > ACK get's uac_replace'd in if(loose_route()) block, but INVITE get's > handled properly. > > Upgrading to 1.4 or 1.3 is risky - or is it not? ;-) - because never > touch a running system, isn't it? > But then that customer comes with that Allied Telesis CPE :-) (And Ati > blames the proxy for not matching the ACK in the CPE although they use > a from-tag, too). > > Many Thanks! > br > Walter > > _______________________________________________ > Users mailing list > Users(a)lists.kamailio.org > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users

2 1

[Kamailio-Users] UAC on ACK in reInvite
by Schober Walter 25 Nov '08

25 Nov '08

Hello All! Tried to fix that anyhow but without success yet. Anyone who could just tell me, if it's fixed in 1.4.something? Scenario: A -> Openser 1.1.1 -> Openser 1.1.1 -> Openser 1.1.1 (UAC:normalize From to phone number in national format) -> B A Invites B => all OK A reInvites B with T.38 -> INVITE => OK <- 200 OK => OK -> ACK => From field not handled by UAC. UAC config all default, so UAC restore mode "auto". Neither INVITE nor ACK get's uac_replace'd in if(loose_route()) block, but INVITE get's handled properly. Upgrading to 1.4 or 1.3 is risky - or is it not? ;-) - because never touch a running system, isn't it? But then that customer comes with that Allied Telesis CPE :-) (And Ati blames the proxy for not matching the ACK in the CPE although they use a from-tag, too). Many Thanks! br Walter

2 1

Re: [Kamailio-Users] Username vs DID
by ingdavidcespedes＠cable.net.co 25 Nov '08

25 Nov '08

----- Mensaje original ----- De: Matteo D'Amato <matteo(a)ecosma.com> Fecha: Martes, Noviembre 25, 2008 10:12 am Asunto: [Kamailio-Users] Username vs DID > Yes I am using a PSTN Gateway, should I create a new table to hold > the link between the username and DID or do I use the information > in the alias table? > > And there may be some local calls between users, so are you saying > it would have been easier to use their actual DID numbers as their > usernames? I have seen something like this ie: PSTN Number: 7565079 Internal Extension:5079 So you use as username= 5079, and PSTN number 7565079. But it's always better, I think, to have internal user names as "John" and associate its DID only when he is trying to reach the PSTN, adding the RFC 3325 header field P-Asserted-Identity with the DID number. > --Matteo

2 1

[Serusers] problem getting calls to my gateway
by G. Ricca 25 Nov '08

25 Nov '08

1 0

[Kamailio-Users] Username vs DID
by Matteo D'Amato 25 Nov '08

25 Nov '08

Hello, I have users with one or more DID numbers assigned to them and some with none. What is the standard convention when choosing usernames? Initially I started with usernames with the following format 1001,1002,etc however when a user dials a number their username shows up instead of their DID. I'm assigning DID with the alias command. Is there a way to show their DID number or do I need to change the way I create usernames? --Matteo

2 3

[Kamailio-Users] 100% CPU and crashed coredump available
by Ali Jawad 25 Nov '08

25 Nov '08

Hi I have a high end server and only openser + a couple of calls running, I was not able to logon to the server using my softphone anymore. The server in question is Openser 1.3 The dump file core can be found at http://www.4shared.com/file/72990148/8dca8efd/core.html Regards

3 4

[Kamailio-Users] caller id on AS5350XM
by Mark Anthony C. Delfin 25 Nov '08

25 Nov '08

Hi List, We have some issue when we are restricting caller id to a particular sip carrier using a Cisco 5350XM. The cisco 5350XM sends the from header as From: "anonymous" <sip:0xxxxxx0@xx.yy.zz.99 <sip%3A0282073300(a)202.85.241.99>>;tag=1F480924-17D9 but the sip provider's SBC is case sensitive and requires From: "Anonymous" <sip:0282073300@xx.yy.zz.99<sip%3A0282073300(a)202.85.241.99> >;tag=1F480924-17D9. I can't find a config on Cisco to change anonymous to Anonymous. Does anyone knows how to change this on the AS5350XM. Thank you. Regards, Mark Anthony C. Delfin

2 1

[Kamailio-Users] OpenSER v1.3.4 released
by Daniel-Constantin Mierla 24 Nov '08

24 Nov '08

Hello, a new release in 1.3 series is out. OpenSER (new project name: Kamailio) 1.3.4 is based on the latest version of branch 1.3, including many fixes in code and documentation, therefore those running 1.3.x are advised to upgrade. Source tarballs are available at: http://www.kamailio.org/pub/kamailio/1.3.4/src/ <http://www.kamailio.org/pub/openser/1.3.4/src> Detailed changelog: http://www.kamailio.org/pub/openser/1.3.4/ChangeLog Download via SVN: svn co https://openser.svn.sourceforge.net/svnroot/openser/branches/1.3 kamailio Tag for this release can be browsed at: http://openser.svn.sourceforge.net/viewvc/openser/tags/1.3.4/ Project site at SourceForge.net: http://sourceforge.net/projects/openser/ Modules' documentation: http://www.kamailio.org/docs/modules/1.3.x/ <http://www.kamailio.org/docs/modules/1.3.x> What is new in 1.3.x release series is summarized in the announcement of v1.3.0: http://www.kamailio.org/mos/view/OpenSER-v1.3.x-Release-Notes/ <http://www.kamailio.org/mos/view/OpenSER-v1.3.x-Release-Notes> /Note: Kamailio is the new name of OpenSER project. First version under Kamailio name was 1.4.0. Older versions will continue to use OpenSER name. / Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

1 0

Re: [Kamailio-Users] Is PRACK Supported?
by ingdavidcespedes＠cable.net.co 24 Nov '08

24 Nov '08

Thanks Alex That was exactly what I wanted to know, if it could relay PRACK messages and associate them with the corresponding provisional response message. ----- Mensaje original ----- De: Alex Balashov <abalashov(a)evaristesys.com> Fecha: Lunes, Noviembre 24, 2008 2:28 pm Asunto: Re: [Kamailio-Users] Is PRACK Supported? > Yes. But it is up to the endpoint to send the PRACK in response to > a > non-100 provisional message sent reliably, not the proxy, so > Kamailio > doesn't really need to 'support' anything related to the PRACK > method > other than relaying it, which it will. > > ingdavidcespedes(a)cable.net.co wrote: > > > Hi > > > > Does anyone know if RFC 3262 and its PRACK response are > supported by Kamailio? How can I implement it? > > > > Thanks in advance. > > > > David Cespedes > > > > > > _______________________________________________ > > Users mailing list > > Users(a)lists.kamailio.org > > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users > > > -- > Alex Balashov > Evariste Systems > Web : http://www.evaristesys.com/ > Tel : (+1) (678) 954-0670 > Direct : (+1) (678) 954-0671 > Mobile : (+1) (706) 338-8599 >

3 3

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