- sr-users - kamailio.org

[Kamailio-Users] Siptrace and Kamailio 3.0.0
by Kris Amy 11 Feb '10

11 Feb '10

Hi, Just wondering if anyone is using Siptrace with Kamailio 3.0.0. The module fails to load and I have no idea why (or how to get more information than from debug = 99). 0(13453) DEBUG: <core> [sr_module.c:871]: DEBUG: init_mod: siptrace 0(13453) ERROR: <core> [sr_module.c:874]: init_mod(): Error while initializing module siptrace ERROR: error while initializing modules Cheers, Kris

2 4

[Kamailio-Users] kamailio crashes during connection attempt
by Dmitri 10 Feb '10

10 Feb '10

Hello list, I have fresh installation of Debian Squeeze on X86_64. I downloaded source tarball http://www.kamailio.org/pub/kamailio/latest/src/kamailio-3.0.0_src.tar.gz and did 'make deb' there. So, I got following debian packages: kamailio_3.0.0_amd64.deb, kamailio-berkeley-modules_3.0.0_amd64.deb, kamailio-carrierroute-modules_3.0.0_amd64.deb kamailio-cpl-modules_3.0.0_amd64.deb, kamailio-ldap-modules_3.0.0_amd64.deb, kamailio-memcached-modules_3.0.0_amd64.deb kamailio-mysql-modules_3.0.0_amd64.deb, kamailio-nth_3.0.0_amd64.deb, kamailio-perl-modules_3.0.0_amd64.deb kamailio-postgres-modules_3.0.0_amd64.deb, kamailio-presence-modules_3.0.0_amd64.deb, kamailio-purple-modules_3.0.0_amd64.deb kamailio-radius-modules_3.0.0_amd64.deb, kamailio-snmpstats-modules_3.0.0_amd64.deb, kamailio-tls-modules_3.0.0_amd64.deb kamailio-unixodbc-modules_3.0.0_amd64.deb, kamailio-utils-modules_3.0.0_amd64.deb, kamailio-xmlrpc-modules_3.0.0_amd64.deb kamailio-xmpp-modules_3.0.0_amd64.deb I installed packages: kamailio_3.0.0_amd64.deb, kamailio-mysql-modules_3.0.0_amd64.deb, kamailio-presence-modules_3.0.0_amd64.deb, kamailio-xmlrpc-modules_3.0.0_amd64.deb Created database, changed passwords for openser and openserro users in MySQL as well as in kamailio config files, enabled MySQL. DUMP_CORE=yes in /etc/default/kamailio, also added '-w /var/run/kamailio' to options. Created test user with kamctl. Started kamailio with init script: /etc/init.d/kamailio start: Feb 7 22:05:10 kamailio kamailio: INFO: <core> [tcp_main.c:4150]: init_tcp: using epoll_lt as the io watch method (auto detected) Feb 7 22:05:10 kamailio /usr/sbin/kamailio[2678]: INFO: usrloc [hslot.c:53]: locks array size 512 Feb 7 22:05:10 kamailio /usr/sbin/kamailio[2678]: INFO: <core> [udp_server.c:166]: INFO: udp_init: SO_RCVBUF is initially 124928 Feb 7 22:05:10 kamailio /usr/sbin/kamailio[2678]: INFO: <core> [udp_server.c:217]: INFO: udp_init: SO_RCVBUF is finally 262142 Feb 7 22:05:10 kamailio /usr/sbin/kamailio[2678]: INFO: <core> [udp_server.c:166]: INFO: udp_init: SO_RCVBUF is initially 124928 Feb 7 22:05:10 kamailio /usr/sbin/kamailio[2678]: INFO: <core> [udp_server.c:217]: INFO: udp_init: SO_RCVBUF is finally 262142 Feb 7 22:05:10 kamailio /usr/sbin/kamailio[2678]: INFO: <core> [udp_server.c:166]: INFO: udp_init: SO_RCVBUF is initially 124928 Feb 7 22:05:10 kamailio /usr/sbin/kamailio[2678]: INFO: <core> [udp_server.c:217]: INFO: udp_init: SO_RCVBUF is finally 262142 Feb 7 22:05:10 kamailio /usr/sbin/kamailio[2695]: INFO: ctl [io_listener.c:224]: io_listen_loop: using epoll_lt io watch method (config) Then I tried to connect to kamailio server with softphone Zoiper, and kamailio crashes immediately: Feb 7 22:05:20 kamailio /usr/sbin/kamailio[2700]: : <core> [pass_fd.c:283]: ERROR: receive_fd: EOF on 21 Feb 7 22:05:20 kamailio kernel: [ 1051.407643] kamailio[2689]: segfault at c2 ip 00007fa8b5947b19 sp 00007fff48ff9700 error 4 in tm.so[7fa8b5917000+72000] Feb 7 22:05:20 kamailio /usr/sbin/kamailio[2678]: ALERT: <core> [main.c:722]: child process 2689 exited by a signal 11 Feb 7 22:05:20 kamailio /usr/sbin/kamailio[2678]: ALERT: <core> [main.c:725]: core was not generated Feb 7 22:05:20 kamailio /usr/sbin/kamailio[2678]: INFO: <core> [main.c:737]: INFO: terminating due to SIGCHLD Feb 7 22:05:20 kamailio /usr/sbin/kamailio[2691]: INFO: <core> [main.c:788]: INFO: signal 15 received Feb 7 22:05:20 kamailio /usr/sbin/kamailio[2699]: INFO: <core> [main.c:788]: INFO: signal 15 received Feb 7 22:05:20 kamailio /usr/sbin/kamailio[2698]: INFO: <core> [main.c:788]: INFO: signal 15 received Feb 7 22:05:20 kamailio /usr/sbin/kamailio[2687]: INFO: <core> [main.c:788]: INFO: signal 15 received Feb 7 22:05:20 kamailio /usr/sbin/kamailio[2697]: INFO: <core> [main.c:788]: INFO: signal 15 received Feb 7 22:05:20 kamailio /usr/sbin/kamailio[2690]: INFO: <core> [main.c:788]: INFO: signal 15 received Feb 7 22:05:20 kamailio /usr/sbin/kamailio[2696]: INFO: <core> [main.c:788]: INFO: signal 15 received Feb 7 22:05:20 kamailio /usr/sbin/kamailio[2688]: INFO: <core> [main.c:788]: INFO: signal 15 received Feb 7 22:05:20 kamailio /usr/sbin/kamailio[2695]: INFO: <core> [main.c:788]: INFO: signal 15 received Feb 7 22:05:20 kamailio /usr/sbin/kamailio[2680]: INFO: <core> [main.c:788]: INFO: signal 15 received Feb 7 22:05:20 kamailio /usr/sbin/kamailio[2694]: INFO: <core> [main.c:788]: INFO: signal 15 received Feb 7 22:05:20 kamailio /usr/sbin/kamailio[2693]: INFO: <core> [main.c:788]: INFO: signal 15 received Feb 7 22:05:20 kamailio /usr/sbin/kamailio[2692]: INFO: <core> [main.c:788]: INFO: signal 15 received Feb 7 22:05:20 kamailio /usr/sbin/kamailio[2686]: INFO: <core> [main.c:788]: INFO: signal 15 received Feb 7 22:05:20 kamailio /usr/sbin/kamailio[2685]: INFO: <core> [main.c:788]: INFO: signal 15 received Feb 7 22:05:20 kamailio /usr/sbin/kamailio[2681]: INFO: <core> [main.c:788]: INFO: signal 15 received Feb 7 22:05:20 kamailio /usr/sbin/kamailio[2684]: INFO: <core> [main.c:788]: INFO: signal 15 received Feb 7 22:05:20 kamailio /usr/sbin/kamailio[2682]: INFO: <core> [main.c:788]: INFO: signal 15 received Feb 7 22:05:20 kamailio /usr/sbin/kamailio[2700]: INFO: <core> [main.c:788]: INFO: signal 15 received Feb 7 22:05:20 kamailio /usr/sbin/kamailio[2683]: INFO: <core> [main.c:788]: INFO: signal 15 received Feb 7 22:05:20 kamailio /usr/sbin/kamailio[2678]: ERROR: ctl [ctl.c:379]: ERROR: ctl: could not delete unix socket /tmp/ser_ctl: Operation not permitted (1) Feb 7 22:05:20 kamailio kernel: [ 1051.432646] kamailio[2678]: segfault at 12 ip 00007fa8b592ae43 sp 00007fff48ff9f40 error 4 in tm.so[7fa8b5917000+72000] For unknown reason core was not generated. Any ideas ? Many thanks in advance, Dmitri

5 35

[Kamailio-Users] save() function
by Kris Amy 10 Feb '10

10 Feb '10

Hi All, It was to my understanding that this function was part of the core and thus didn't come from a module. The relevant code snippet is if(!save("location")) { xlog("L_ERR", "Saving contact failed - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); sl_reply_error(); exit; } The error I'm getting is.. 0(20467) DEBUG: <core> [sr_module.c:516]: find_export_record: <save> not found 0(20467) DEBUG: <core> [sr_module.c:516]: find_export_record: <save> not found 0(20467) : <core> [cfg.y:3329]: parse error in config file /etc/kamailio/kamailio.cfg, line 656, column 21: unknown command, missing loadmodule? Cheers, Kris

2 2

[Kamailio-Users] Carrierroute issue
by michel freiha 10 Feb '10

10 Feb '10

Hi all, I'm using carrierroute module and ie seems that it's not working well...Suppose I have 2 entries in carrierroute table...Entry 1 with scan prefix 00 and prob 0 and a second entry with scan prefix 00 and prob=1...As soon as i make a call, this call will be forwarded to the entry with prob 0 because i guess it appears before the one with prob 1 in the table... When starting Kamailio I got the below: Jul 29 12:30:11 [23143] INFO:carrierroute:add_route: adding prefix 1, prob -14931260.000000 Jul 29 12:30:11 [23143] INFO:carrierroute:get_route_tree: domain 0 not found, add it Jul 29 12:30:11 [23143] INFO:carrierroute:add_route_tree: tree default has 1 trees Jul 29 12:30:11 [23143] DBG:carrierroute:add_route_tree: tree 0Jul 29 12:30:11 [23143] INFO:carrierroute:get_route_tree: created route tree: 0, with id 0 Jul 29 12:30:11 [23143] INFO:carrierroute:add_route: found route, now adding Jul 29 12:30:11 [23143] INFO:carrierroute:add_route_rule: no backed up rules Jul 29 12:30:11 [23143] INFO:carrierroute:add_route: adding prefix , prob -14931260.000000 Jul 29 12:30:11 [23143] INFO:carrierroute:get_route_tree: found domain 0 Jul 29 12:30:11 [23143] INFO:carrierroute:add_route: found route, now adding Jul 29 12:30:11 [23143] INFO:carrierroute:add_route_rule: no backed up rules Jul 29 12:30:11 [23143] INFO:carrierroute:add_route: adding prefix 011, prob -14931260.000000 Jul 29 12:30:11 [23143] INFO:carrierroute:get_route_tree: found domain 0 Jul 29 12:30:11 [23143] INFO:carrierroute:add_route: found route, now adding Jul 29 12:30:11 [23143] INFO:carrierroute:add_route_rule: no backed up rules Jul 29 12:30:11 [23143] INFO:carrierroute:add_route: adding prefix 00, prob -14931260.000000 Jul 29 12:30:11 [23143] INFO:carrierroute:get_route_tree: found domain 0 Jul 29 12:30:11 [23143] INFO:carrierroute:add_route: found route, now adding Jul 29 12:30:11 [23143] INFO:carrierroute:add_route_rule: no backed up rules Jul 29 12:30:11 [23143] INFO:carrierroute:add_route: adding prefix 111, prob -14931260.000000 Jul 29 12:30:11 [23143] INFO:carrierroute:get_route_tree: found domain 0 Jul 29 12:30:11 [23143] INFO:carrierroute:add_route: found route, now adding Jul 29 12:30:11 [23143] INFO:carrierroute:add_route_rule: no backed up rules Jul 29 12:30:11 [23143] INFO:carrierroute:add_route: adding prefix 00, prob -14931260.000000 Jul 29 12:30:11 [23143] INFO:carrierroute:get_route_tree: found domain 0 Jul 29 12:30:11 [23143] INFO:carrierroute:add_route: found route, now adding Jul 29 12:30:11 [23143] INFO:carrierroute:add_route_rule: no backed up rules Jul 29 12:30:11 [23143] INFO:carrierroute:add_route: adding prefix , prob -14931260.000000 Jul 29 12:30:11 [23143] INFO:carrierroute:get_route_tree: found domain 0 Jul 29 12:30:11 [23143] INFO:carrierroute:add_route: found route, now adding Jul 29 12:30:11 [23143] INFO:carrierroute:add_route_rule: no backed up rules Jul 29 12:30:11 [23143] INFO:carrierroute:add_route: adding prefix 011, prob -14931260.000000 Jul 29 12:30:11 [23143] INFO:carrierroute:get_route_tree: found domain 0 Jul 29 12:30:11 [23143] INFO:carrierroute:add_route: found route, now adding Jul 29 12:30:11 [23143] INFO:carrierroute:add_route_rule: no backed up rules Jul 29 12:30:11 [23143] INFO:carrierroute:add_route: adding prefix 011, prob -14931260.000000 Jul 29 12:30:11 [23143] INFO:carrierroute:get_route_tree: found domain 0 Jul 29 12:30:11 [23143] INFO:carrierroute:add_route: found route, now adding Jul 29 12:30:11 [23143] INFO:carrierroute:add_route_rule: no backed up rules Jul 29 12:30:11 [23143] INFO:carrierroute:add_route: adding prefix , prob -14931260.000000 Jul 29 12:30:11 [23143] INFO:carrierroute:get_route_tree: found domain 0 Jul 29 12:30:11 [23143] INFO:carrierroute:add_route: found route, now adding Jul 29 12:30:11 [23143] INFO:carrierroute:add_route_rule: no backed up rules It seems that kamailio is not reading probability entry in carrier route table Please find below carrierroute table structure: CREATE TABLE IF NOT EXISTS `carrierroute` ( `id` int(10) unsigned NOT NULL auto_increment, `carrier` int(10) unsigned NOT NULL default '0', `domain` varchar(64) NOT NULL default '', `scan_prefix` varchar(64) NOT NULL default '', `flags` int(11) unsigned NOT NULL default '0', `mask` int(11) unsigned NOT NULL default '0', `prob` float NOT NULL default '0', `strip` int(11) unsigned NOT NULL default '0', `rewrite_host` varchar(128) NOT NULL default '', `rewrite_prefix` varchar(64) NOT NULL default '', `rewrite_suffix` varchar(64) NOT NULL default '', `description` varchar(255) default NULL, PRIMARY KEY (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=23 ; Can someone help me to find this issue? Regards

5 13

[Kamailio-Users] check_user_blacklist function
by Antonio Reale 10 Feb '10

10 Feb '10

Hi all, the function check_user_blacklist in kamailio 1.4 returns -1 (FALSE based on the doc) "if a match is found and it is not set to whitelist", otherwise it returns 1 (TRUE). So the function returns the same value if a match is found and is set to whitelist and if there are no matches. I need to differentiate the two situations. The userblacklist module in kamailio 3.0 has a new function "check_user_whitelist" that can solve my problem, but at this time I can't upgrade. I solved the problem, changing only the return value in case of whitelisted entry (userblacklist.c file), but I don't know if it is a safe (and suffice) modification. Below the piece of code in the userblacklist.c: if (dt_longest_match(dt_root, ptr, &whitelist) >= 0) { if (whitelist) { /* LM_ERR("whitelisted"); */ return 2; /* found, but is whitelisted */ <===== CHANGED HERE. IT WAS return 1 } } else { /* LM_ERR("not found"); */ return 1; /* not found is ok */ } Thanks. Regards. -- Antonio

2 2

[Kamailio-Users] LCR
by Kris Amy 10 Feb '10

10 Feb '10

Hi All, I've been ripping my hair out for a little with load_gws(). How do I know what the lcr_id is and the caller_uri? I would have thought that $fu for caller_uri would have been sufficient but it seems not. Cheers, Kris

3 2

[Kamailio-Users] kamctl and lcr table
by Kris Amy 10 Feb '10

10 Feb '10

Hi, Could we get the lcr-create.sql updated to have the ping field? Cheers, Kris

2 3

[Kamailio-Users] irc devel meeting
by Daniel-Constantin Mierla 09 Feb '10

09 Feb '10

Hello, I was thinking of having an IRC meeting to discuss next steps within sip router. Now that 3.0 branches are out for a while, would be good to plan a bit 3.1. For me Friday (or even Thursday if not too early for others to make arrangements) this week would be good, say 14:00 or 15:00UTC to allow fair time for US. If this date does not fit, please make proposals. The channel is #sip-router on freenode.net. Cheers, Daniel -- Daniel-Constantin Mierla eLearning class for Kamailio 3.0.0 * http://www.asipto.com/

1 0

[Kamailio-Users] problems with mi_xmlrpc command
by Anton Roman 09 Feb '10

09 Feb '10

Hi all, I'm trying to send xmlrpc commands to Kamailio with Siremis but I get the error below: Fault Code: 5 Fault Reason: Didn't receive 200 OK from remote server. (HTTP/1.1 400 Bad Request) I get the same error when I manually send the xmlrpc command with curl. On the other hand, mi_xmlrpc module seems to be correctly loaded, but nothing is written in the log file (set with modparam("mi_xmlrpc", "log_file", "/var/log/abyss.log")). Does anybody know where the problem might be? Best regards, thanks in advance. Anton Roman These are the traces of the xmlrpc message flow: T +11.569284 127.0.0.1:37821 -> 127.0.0.1:8080 [AP] POST HTTP/1.0 User-Agent: PEAR XML_RPC Host: 127.0.0.1 Content-Type: text/xml Content-Length: 135 <?xml version="1.0" encoding="UTF-8"?> <methodCall> <methodName>system.listMethods</methodName> <params> </params> </methodCall> ## T +0.000363 127.0.0.1:8080 -> 127.0.0.1:37821 [AP] HTTP/1.1 400 Bad Request # T +0.000146 127.0.0.1:8080 -> 127.0.0.1:37821 [AP] Content-type: text/html # T +0.001982 127.0.0.1:8080 -> 127.0.0.1:37821 [AFP] Connection: close Date: Mon, 08 Feb 2010 14:04:08 GMT Server: XMLRPC_ABYSS/1.06 <HTML><HEAD><TITLE>Error 400</TITLE></HEAD><BODY><H1>Error 400</H1><P>Bad Request</P><p><HR><b><i><a href="http://xmlrpc-c.sourceforge.net">ABYSS Web Server for XML-RPC For C/C++</a></i></b> version 1.06<br></p></BODY></HTML> ####

2 2

[Kamailio-Users] Stateless forward
by Antonio Reale 09 Feb '10

09 Feb '10

Hi all, I'm trying to setup a very basic scenario with kamailio 3.0. It is placed in front of a softswitch and it has to modify some headers before forward (stateless) messages to softswitch. If I use route { rewritehost("192.168.10.1"); t_relay(); } all work, but if I want to do that stateless and I use forward() or send() instead of t_relay(), I get a syntax error: "bad forward argument" or "bad send argument". If I use ... forward("udp:192.168.10.1:5060"); ... I see in the log /usr/local/sbin/kamailio[3675]: : <core> [proxy.c:271]: ERROR: mk_proxy: could not resolve hostname: "udp:192.168.10.1:5060" /usr/local/sbin/kamailio[3675]: ERROR: <core> [route.c:1026]: fixing failed (code=-478) at cfg:/usr/local/etc/kamailio/kamailio.cfg:77 Same error using the long format of send() function. I can't see any particular hint on the documentation, what I'm missing? Thank you. Best regards. -- Antonio

3 6

[Kamailio-Users] Install Documentation
by Kris Amy 09 Feb '10

09 Feb '10

Hi All, Just thought that you might want to put down that libpcre is required for lcr in the install document. (Since the other main modules have their requirements listed). Cheers, Kris

2 1

[Kamailio-Users] change domain at to header
by Adnan Çelikel 09 Feb '10

09 Feb '10

Dear All, I want to change a field (Sip to address host part) at sip message header. I think avpops will solve this.If anybody has a sample confg and send to me I will be very glad.Regards,Adnan. #---------------------------------------------------- #7777 CALL ROUTING #-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* if(is_method("INVITE") && (uri=~"sip:7777")){ rewritehostport("192.168.1.10:5060"); route(1); exit; } #---------------------------------------------------- at this rule, the invite is going to 192.168.1.10 with the host part as abc.com, we want to send with another domain. Instead of abc.com domain, I want to use 192.168.1.10 domain ; To:<sip:7777@abc.com> To:<sip:7777@192.168.1.10> _________________________________________________________________ Windows Live Hotmail: Arkadaşlarınız Facebook'taki güncellemelerinizi doğrudan Hotmail®'den alır. http://www.microsoft.com/windows/windowslive/see-it-in-action/social-networ…

5 11

Routing Problems
by Andreas Rehbein 08 Feb '10

08 Feb '10

Hello, we use Kamailio 3.0 on a Red Hat EL5.4 system with openssl 0.9.8e (the current Red Hat OpenSSL version). We want to use Kamailio 3.0 in front of our Call Server (OpenSER 1.3.2) as a security gateway. So the Call Server should only deal tcp, while the Security Gateway terminates the TLS Data which he receives from the User Agents but forwards the SIP-Messages via TCP to the Call Server. UA ---SIP_over_TLS---> Security Gateway (Kam3.0) ---SIP_over_TCP---> Call Server (OpenSER1.3.2) UA<---SIP_over_TLS--- Security Gateway (Kam3.0) <---SIP_over_TCP--- Call Server (OpenSER1.3.2) Nearly everything works fine in this scenario: User Agents are able to register and when they are sending INVITES the callee receives it. The problem we have right now is: if Kamailio 3.0 receives BYE we get 477 Unfortunatly error on sending to next hop occured. It seems that the messages are ok... I attached a text file with the BYE message and the errors. Explanation for the text file: * UA1: 192.168.0.126 * UA2: 192.168.0.176 *Security Gateway (Kam3.0): 192.168.0.89 *Call Server (OpenSER1.3.2): 192.168.0.106 Do you have any suggestions? Thank you very much in advance! Regards Andreas Dipl.-Ing. (FH) Andreas Rehbein FH Frankfurt am Main - University of Applied Sciences FB 2 - Informatik und Ingenieurwissenschaften Forschungsgruppe für Telekommunikationsnetze Kleiststraße 3 60318 Frankfurt am Main Tel.: +49 (0) 69 1533 3613 Fax: +49 (0) 69 1539 5224 961 E-Mail: <mailto:rehbein@e-technik.org> rehbein(a)e-technik.org Internet: <http://www.e-technik.org/frame_forschung.htm> http://www.e-technik.org/frame_forschung.htm

2 2

[Kamailio-Users] Maximum retries exceeded on transmission
by Daniel-Constantin Mierla 06 Feb '10

06 Feb '10

On Sat, Feb 6, 2010 at 11:10 AM, Jon Farmer <viperdudeuk(a)gmail.com> wrote: > Sorry it was a problem I had with gmail. > It happens to me from time to time, but I couldn't find the real cause, whether is gmail or thunderbird. Thunderbird hangs a while, reports a delivery error, then message appears twice... Daniel > On 5 Feb 2010 12:21, "Iñaki Baz Castillo" <ibc(a)aliax.net> wrote: > > 2010/2/5 Jon Farmer <viperdudeuk(a)gmail.com>: > > Hi > > Please don't send the same smail twice. Thanks. > > > _______________________________________________ > 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 -- Daniel-Constantin Mierla http://www.asipto.com

1 0

[Kamailio-Users] Maximum retries exceeded on transmission
by Daniel-Constantin Mierla 06 Feb '10

06 Feb '10

Hello, On Fri, Feb 5, 2010 at 10:56 AM, Jon Farmer <viperdudeuk(a)gmail.com> wrote: > Hi > > I am getting this dreaded error on a asterisk box when call from one > UA to another using Asterisk as a media relay and openser as a SBC and > proxy. > > chan_sip.c:3779 retrans_pkt: Maximum retries exceeded on transmission > 1310650592(a)10.100.0.101 > > If I make a call from a UA to the PSTN through Asterisk all is > fine. This only happens when calling from one UA to another on the > same LAN. > > I have posted an example sip trace here http://pastebin.com/m2262b0ef > ACK is not accepted as I could spot quickly, 200ok being retransmitted. Probably there is something wrong with dialog attributes, after Fosdem I can check it better. Daniel > My openser.cfg is here http://pastebin.com/d5e84aaf7 > > I realise this is a issue with Asterisk but I have not been able to > find a fix. Therefore I figure there might be something I can do on > openser. The problem seems to be with a ACK not being returned but my > SIP knowledge is not good enough to know how to fix it. Any help is > greatly appreciated. > > Regards > > Jon > -- > Jon Farmer > Tel: 07795 118140 > Email: viperdudeuk(a)gmail.com > Twitter: @viperdudeuk > > _______________________________________________ > 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 -- Daniel-Constantin Mierla http://www.asipto.com

1 0

[Kamailio-Users] Maximum retries exceeded on transmission
by Jon Farmer 06 Feb '10

06 Feb '10

Hi I am getting this dreaded error on a asterisk box when call from one UA to another using Asterisk as a media relay and openser as a SBC and proxy. chan_sip.c:3779 retrans_pkt: Maximum retries exceeded on transmission 1310650592(a)10.100.0.101 If I make a call from a UA to the PSTN through Asterisk all is fine. This only happens when calling from one UA to another on the same LAN. I have posted an example sip trace here http://pastebin.com/m2262b0ef My openser.cfg is here http://pastebin.com/d5e84aaf7 I realise this is a issue with Asterisk but I have not been able to find a fix. Therefore I figure there might be something I can do on openser. The problem seems to be with a ACK not being returned but my SIP knowledge is not good enough to know how to fix it. Any help is greatly appreciated. Regards Jon -- Jon Farmer Tel: 07795 118140 Email: viperdudeuk(a)gmail.com Twitter: @viperdudeuk

2 2

[Serusers] RECEIVED column in SER.LOCATION table
by Bill McNamara 05 Feb '10

05 Feb '10

Question, when does a value get inserted into the ser.location table’s received column. We have some UA’s with a contact like value and some with null values – different devices (Polycom 331/450/55, Grandstream 286/486) behind the same firewall. I’m just curious to know why some have a received value and some don’t. Thanks, Bill SER 2.0 Linux 2.6.9-78 x86_64 MySQL 5.1.30

2 1

[Kamailio-Users] CRITICAL:dialog:log_next_state_dlg
by alex pappas 05 Feb '10

05 Feb '10

Dear users, I'm doing some stress test with kamailio 1.5. When I'm at 50 CPS a see some strange messages: /usr/sbin/kamailio[12754]: CRITICAL:dialog:log_next_state_dlg: bogus event 2 in state 3 for dlg 0x2b0b911831b0 [3345:993496027] with clid '297-19089@IP-address' and tags '19089SIPpTag00297' '15519SIPpTag01304' Does anyone before experienced this before? Thanks Alex

1 0

[Kamailio-Users] Maximum retries exceed on transmission
by Jon Farmer 05 Feb '10

05 Feb '10

Hi I am getting this dreaded error on a asterisk box when call from one UA to another using Asterisk as a media relay and openser as a SBC and proxy. If I make a call from a UA to the PSTN through Asterisk all is fine. This only happens when calling from one UA to another on the same LAN. I have posted an example sip trace here http://pastebin.com/m2262b0ef My openser.cfg is here http://pastebin.com/d5e84aaf7 I realise this is a issue with Asterisk but I have not been able to find a fix. Therefore I figure there might be something I can do on openser. The problem seems to be with a ACK not being returned but my SIP knowledge is not good enough to know how to fix it. Any help is greatly appreciated. Regards Jon -- Jon Farmer Tel: 07795 118140 Email: viperdudeuk(a)gmail.com Twitter: @viperdudeuk

3 5

[Kamailio-Users] new: interactive debugger for config
by Daniel-Constantin Mierla 05 Feb '10

05 Feb '10

Hello, the new debugger module can be used to do runtime debugging of SIP Router config file, in similar manner of gdb. The module is controlled via the RPC interface, therefore investigation can be done from a remote site. That makes it very handy to use with sercmd as well. One features is to print a log message for each action executed in the config for a SIP message, showing the execution path. The option can be enabled/disabled per process. The other one is step by step execution of config file. When a SIP message message comes it, SIP Router process will stop at first action and wait for commands, like: execute the action, evaluate a pseduo-variable, print to syslog a pseudo-variable, remove the breakpoints and continue execution without interruption, ... See the readme for more: http://sip-router.org/docbook/sip-router/branch/master/modules/debugger/deb… It is still some stuff to complete, some known issues to remove, but the module is usable and may help some of you to troubleshoot migrations from older versions to 3.0 (use master branch until your config is updated and running fine, then use it with stable 3.0). Hope is going to be useful and waiting for feedback to improve. Of course, contributions are most welcome! Cheers, Daniel -- Daniel-Constantin Mierla eLearning class for Kamailio 3.0.0 Starting Feb 8, 2010 * http://www.asipto.com/

4 5

[Kamailio-Users] Kamailio/SIPRouter Training
by Bruce McAlister 05 Feb '10

05 Feb '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi All, Are there any planned dates for Kamailio/SIPRouter training events around Europe in the next couple months. Looking forward to your replies..... Thanks Bruce -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLa+kVAAoJEGJOkoTLLvBntMUIAJZEb7AaFDAdwKmTxlyokq30 A5eebX8mTUXk9fkzcHX0IoRRrl8eQKGqUbIl2312oQZtxJrffTksY3xiFFOdpBCp 78RDmKjLvmhAwq7jYPExk91BiV4no+dcAKuHsntwz8EfW9uHd34NRlp+TEc8Q2A8 QB7Ztfq8J+8KjGWJoRE27gqiHEIwZp7F7/rvn4N/VAuaTcaTtYhaiI52iIOA+aNM UTgkGMVzjjpPrwXh7C/DZERKThTifF01PzCx1DSlPiMczrGCGxHy8NEgAaHHsXb9 yrrtd/B4qWAbaYT8mRXisw9hNaGktdmCAA6Ksrq/xz/qjjVa84Tflo9d754PTGw= =kgI0 -----END PGP SIGNATURE-----

1 0

[Kamailio-Users] load_credentials problem
by Dubravko Caric 05 Feb '10

05 Feb '10

Hi all, i have a problem when using AVPs which are loaded on client registration by the "load_credentials". in the "subscriber" table i have "rpid" column (value 12345), "email address" (bob(a)example.com) and "acl" (value 3). when client registers, these three AVPs are loaded as you can see in debug. But when i want to use these AVPs it seems that they are empty. i don't understand if they are ready for use or do i need to load them and how? i'm not doing any actions on AVPs so i could by mistake delete or replace the original ones... version of kamailio is 1.5.1 Thanks Dubravko modparam("auth_db", "load_credentials", "$avp(i:66)=rpid;email_address;$avp(i:67)=acl") DBG:db_mysql:db_mysql_get_columns: allocate 16 bytes for RES_NAMES[0] at 0x783400 DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x783400)[0]=[password] DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type DBG:db_mysql:db_mysql_get_columns: allocate 16 bytes for RES_NAMES[1] at 0x783420 DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x783420)[1]=[acl] DBG:db_mysql:db_mysql_get_columns: use DB_INT result type DBG:db_mysql:db_mysql_get_columns: allocate 16 bytes for RES_NAMES[2] at 0x783440 DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x783440)[2]=[email_address] DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type DBG:db_mysql:db_mysql_get_columns: allocate 16 bytes for RES_NAMES[3] at 0x783460 DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x783460)[3]=[rpid] DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type DBG:core:db_allocate_rows: allocate 16 bytes for rows at 0x783480 DBG:core:db_allocate_row: allocate 128 bytes for row values at 0x7834a0 DBG:core:db_str2val: converting STRING [1234] DBG:core:db_str2val: converting INT [3] DBG:core:db_str2val: converting STRING [bob(a)example.com] DBG:core:db_str2val: converting STRING [12345] DBG:auth_db:get_ha1: HA1 string calculated: 649766733fe475191f6c32d338aae51d DBG:auth:check_response: our result = 'f929dd9729d3c9447c4a4d632a762c85' DBG:auth:check_response: authorization is OK DBG:auth:post_auth: nonce index= 0 DBG:auth_db:generate_avps: set int AVP ""/67 = 3 DBG:auth_db:generate_avps: set string AVP "email_address"/0 = "bob(a)example.com" DBG:auth_db:generate_avps: set string AVP ""/66 = "12345" DBG:core:db_free_columns: freeing 4 columns ################# if (is_method("INVITE")) { xlog("L_INFO", "RPID AVP VALUE $avp(i:66)\n"); xlog("L_INFO", "EMAIL AVP VALUE $avp(s:email_address)\n"); xlog("L_INFO", "ACL AVP VALUE $avp(i:67)\n"); } ./kamailio[21687]: PRID AVP VALUE <null> ./kamailio[21687]: EMAIL AVP VALUE <null> ./kamailio[21687]: ACL AVP VALUE <null>

4 5

[Kamailio-Users] Kamailio v1.5.4 and v1.4.5 released
by Daniel-Constantin Mierla 05 Feb '10

05 Feb '10

Hello, Kamailio version 1.5.4 is out, built from latest svn version of SVN branch 1.5. All details about it are available at: http://www.kamailio.org/mos/view/News/NewsItem/Kamailio-v1.5.4-Released/ Also Kamailio v1.4.5 was released to mark the end of official maintenance for SVN branch 1.4. Details at: http://www.kamailio.org/mos/view/News/NewsItem/Kamailio-v1.4.5-Released/ If you are using a version from these release series, consider updating to the last one. Personally I recommend that you upgrade to the latest stable branch release v3.0.0 -- you get access lot of new features and improvements. Cheers, Daniel

3 5

Re: [Kamailio-Users] [kamailio-users] can't connect with remote database
by Chandrakant Solanki 05 Feb '10

05 Feb '10

On Thu, Feb 4, 2010 at 5:38 PM, Chandrakant Solanki < solanki.chandrakant(a)gmail.com> wrote: > > > On Thu, Feb 4, 2010 at 5:31 PM, marius zbihlei <marius.zbihlei(a)1and1.ro>wrote: > >> Chandrakant Solanki wrote: >> >>> Hi >>> >>> I have 3 server with 172.16.0.10/13/14 <http://172.16.0.10/13/14> IP >>> address. >>> >>> >>> My DB is located for 172.16.0.10. I tried to connect mysql from terminal, >>> it works great. >>> >>> But when I start kamailio it gives me following error.. >>> >>> Hello >> >> Just to double check Have you tried: >> >> mysql --user=openser -p --host=172.16.0.10 openser >> >> from 172.16.0.13 and it works? >> >> From localhost afaik mysql client might use Unix socks(/tmp/mysql.sock) . >> Use should double check that your MySQL server allows TCP connections >> >> Cheers >> >> Marius >> > > Hi mysql --user=openser -p --host=172.16.0.10 openser --socket=/var/lib/mysql/mysql. i have used this command from 172.16.0.13/14 it will works fine and connect to DB on 172.16.0.10 -- Regards, Chandrakant Solanki

1 0

[Kamailio-Users] OK, I've had enough "Ausente"
by Alex Balashov 04 Feb '10

04 Feb '10

Basta. Ya me has dicho que no estás. -- Alex Balashov - Principal Evariste Systems LLC Tel : +1 678-954-0670 Direct : +1 678-954-0671 Web : http://www.evaristesys.com/

3 3

[Kamailio-Users] Openser with MySql Cluster
by Ricardo Coelho 04 Feb '10

04 Feb '10

Hi Right now I have a single openser server configured to work with a single mysql database. I want to enhance availability by adding another openser server and use Mysql Cluster. When failover occurs, despite the fact that he databases have the same data, on one of the softphones i receive a message saying "User not found" and on the other softphone i receive a message saying "Security check failed". Do I need to change something in openser's configuration to make it work with mysql cluster? Thanks in advanced

3 4

Re: [Kamailio-Users] break a call?
by BERGANZ Francois 04 Feb '10

04 Feb '10

Where can I activate it? -----Message d'origine----- De : Klaus Darilion [mailto:klaus.mailinglists@pernau.at] Envoyé : jeudi 4 février 2010 14:09 À : BERGANZ Francois Objet : Re: [Kamailio-Users] break a call? probably the problem is that you can not use tm module functions in onreply_route. You have to handle the responses in the failure route (every final response >=300 triggers the failure_route (if activated)). regards klaus Am 04.02.2010 13:40, schrieb BERGANZ Francois: > Line 254 is t_reply("406", "Not Acceptable"); > > > > -----Message d'origine----- > De : Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > Envoyé : jeudi 4 février 2010 13:08 > À : BERGANZ Francois > Objet : Re: [Kamailio-Users] break a call? > > > > Am 04.02.2010 12:37, schrieb BERGANZ Francois: >> I have that error: >> >> >> onreply_route[1] { >> if(t_check_status("3[0-9][0-9]")){ >> xlog("L_ERR", "3XX!!!!!!!!!!!\n"); >> t_reply("406", "Not Acceptable"); >> exit; >> } >> } >> >> Feb 4 12:36:41 [4584] CRITICAL:core:yyerror: parse error in config >> file, line 254, column 16-17: Command cannot be used in the block > > How will I know what line 254 is? > > The code I sent uses the failure-route, not the reply-route. > > klaus > > >> >> >> Any idea? >> >> Thank you >> >> >> >> -----Message d'origine----- >> De : Klaus Darilion [mailto:klaus.mailinglists@pernau.at] >> Envoyé : jeudi 4 février 2010 08:59 >> À : BERGANZ Francois >> Cc : users(a)lists.kamailio.org >> Objet : Re: [Kamailio-Users] break a call? >> >> e.g.: >> >> failure_route[1] { >> if(t_check_status("302")) { >> xlog("L_INFO","302 redirect received\n"); >> t_reply("403","received 302 from downstream client"); >> exit; >> } >> } >> >> klaus >> >> Am 04.02.2010 08:37, schrieb BERGANZ Francois: >>> Hello, >>> >>> I know that we can break a call with sl_reply(). >>> >>> But, in the on_reply route, how can I break a call if I receive a >>> 3XX (I cant use a sl_reply() function!) ? >>> >>> Thank you >>> >>> >>> >>> _______________________________________________ >>> 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 >> >

2 1

Routing Problems (Sorry, Text file is now included)
by Andreas Rehbein 04 Feb '10

04 Feb '10

Hello, we use Kamailio 3.0 on a Red Hat EL5.4 system with openssl 0.9.8e (the current Red Hat OpenSSL version). We want to use Kamailio 3.0 in front of our Call Server (OpenSER 1.3.2) as a security gateway. So the Call Server should only deal tcp, while the Security Gateway terminates the TLS Data which he receives from the User Agents but forwards the SIP-Messages via TCP to the Call Server. UA ---SIP_over_TLS---> Security Gateway (Kam3.0) ---SIP_over_TCP---> Call Server (OpenSER1.3.2) UA<---SIP_over_TLS--- Security Gateway (Kam3.0) <---SIP_over_TCP--- Call Server (OpenSER1.3.2) Nearly everything works fine in this scenario: User Agents are able to register and when they are sending INVITES the callee receives it. The problem we have right now is: if Kamailio 3.0 receives BYE we get "477 Unfortunatly error on sending to next hop occured". It seems that the messages are ok... I attached a text file with the BYE message and the errors. Explanation for the text file: * UA1: 192.168.0.126 * UA2: 192.168.0.176 *Security Gateway (Kam3.0): 192.168.0.89 *Call Server (OpenSER1.3.2): 192.168.0.106 No. Time Source Destination Protocol Info 101 7.964015 192.168.0.106 192.168.0.89 SIP Request: BYE sip:+497118113608227@192.168.0.89:37260;transport=TLS Frame 101 (1138 bytes on wire, 1138 bytes captured) Ethernet II, Src: AlliedTe_3e:b8:05 (00:15:77:3e:b8:05), Dst: Dell_a0:e2:3f (00:1c:23:a0:e2:3f) Internet Protocol, Src: 192.168.0.106 (192.168.0.106), Dst: 192.168.0.89 (192.168.0.89) Transmission Control Protocol, Src Port: 50445 (50445), Dst Port: sip (5060), Seq: 1234, Ack: 1, Len: 1072 Session Initiation Protocol Request-Line: BYE sip:+497118113608227@192.168.0.89:37260;transport=TLS SIP/2.0 Message Header Record-Route: <sip:192.168.0.106;transport=tcp;lr=on;ftag=ba3448a0> Record-Route: <sip:192.168.0.89;transport=tcp;r2=on;lr=on> Record-Route: <sip:192.168.0.89:5061;transport=tls;r2=on;lr=on> Via: SIP/2.0/TCP 192.168.0.106;branch=z9hG4bK854f.b305c913.0;i=19 Via: SIP/2.0/TCP 192.168.0.89;rport=37260;branch=z9hG4bK854f.dac34f77.0;i=a Via: SIP/2.0/TLS 192.168.0.126:62399;branch=z9hG4bK-d8754z-51f50d6cfa997da7-1---d8754z-;rport =1876 Max-Forwards: 68 Route: <sip:192.168.0.89;transport=tcp;r2=on;lr=on> Route: <sip:192.168.0.89:5061;transport=tls;r2=on;lr=on> Contact: <sip:+497118113608226@192.168.0.89:37260;transport=TLS;rinstance=972e46956fc 87f26> To: "+497118113608227"<sip:+497118113608227@192.168.0.106>;tag=15c25277 From: <sip:+497118113608226@192.168.0.106>;tag=ba3448a0 Call-ID: ZjdiMWY5NTYxMTMyN2Q5NTkwOWVmZWExOTEwMDhjYzQ. CSeq: 2 BYE User-Agent: Bosch Communicator release 2.5.4.2 GAC4 stamp 54836 Reason: SIP;description="User Hung Up" Content-Length: 0 P-hint: rr-enforced No. Time Source Destination Protocol Info 103 7.964791 192.168.0.89 192.168.0.106 SIP Status: 477 Unfortunately error on sending to next hop occurred (477/SL) Frame 103 (887 bytes on wire, 887 bytes captured) Ethernet II, Src: Dell_a0:e2:3f (00:1c:23:a0:e2:3f), Dst: AlliedTe_3e:b8:05 (00:15:77:3e:b8:05) Internet Protocol, Src: 192.168.0.89 (192.168.0.89), Dst: 192.168.0.106 (192.168.0.106) Transmission Control Protocol, Src Port: sip (5060), Dst Port: 50445 (50445), Seq: 1, Ack: 2306, Len: 821 Session Initiation Protocol Status-Line: SIP/2.0 477 Unfortunately error on sending to next hop occurred (477/SL) Message Header Via: SIP/2.0/TCP 192.168.0.106;branch=z9hG4bK854f.b305c913.0;i=19 Via: SIP/2.0/TCP 192.168.0.89;rport=37260;branch=z9hG4bK854f.dac34f77.0;i=a Via: SIP/2.0/TLS 192.168.0.126:62399;branch=z9hG4bK-d8754z-51f50d6cfa997da7-1---d8754z-;rport =1876 To: "+497118113608227"<sip:+497118113608227@192.168.0.106>;tag=15c25277 From: <sip:+497118113608226@192.168.0.106>;tag=ba3448a0 Call-ID: ZjdiMWY5NTYxMTMyN2Q5NTkwOWVmZWExOTEwMDhjYzQ. CSeq: 2 BYE Server: kamailio (3.0.0 (i386/linux)) Content-Length: 0 [truncated] Warning: 392 192.168.0.89:5060 "Noisy feedback tells: pid=10378 req_src_ip=192.168.0.106 req_src_port=50445 in_uri=sip:+497118113608227@192.168.0.89:37260;transport=TLS out_uri=sip:+497118113608227@192.168.0.89:37260;transport No. Time Source Destination Protocol Info 104 7.964845 192.168.0.89 192.168.0.106 SIP Status: 477 Unfortunately error on sending to next hop occurred (477/TM) Frame 104 (887 bytes on wire, 887 bytes captured) Ethernet II, Src: Dell_a0:e2:3f (00:1c:23:a0:e2:3f), Dst: AlliedTe_3e:b8:05 (00:15:77:3e:b8:05) Internet Protocol, Src: 192.168.0.89 (192.168.0.89), Dst: 192.168.0.106 (192.168.0.106) Transmission Control Protocol, Src Port: sip (5060), Dst Port: 50445 (50445), Seq: 822, Ack: 2306, Len: 821 Session Initiation Protocol Status-Line: SIP/2.0 477 Unfortunately error on sending to next hop occurred (477/TM) Message Header Via: SIP/2.0/TCP 192.168.0.106;branch=z9hG4bK854f.b305c913.0;i=19 Via: SIP/2.0/TCP 192.168.0.89;rport=37260;branch=z9hG4bK854f.dac34f77.0;i=a Via: SIP/2.0/TLS 192.168.0.126:62399;branch=z9hG4bK-d8754z-51f50d6cfa997da7-1---d8754z-;rport =1876 To: "+497118113608227"<sip:+497118113608227@192.168.0.106>;tag=15c25277 From: <sip:+497118113608226@192.168.0.106>;tag=ba3448a0 Call-ID: ZjdiMWY5NTYxMTMyN2Q5NTkwOWVmZWExOTEwMDhjYzQ. CSeq: 2 BYE Server: kamailio (3.0.0 (i386/linux)) Content-Length: 0 [truncated] Warning: 392 192.168.0.89:5060 "Noisy feedback tells: pid=10378 req_src_ip=192.168.0.106 req_src_port=50445 in_uri=sip:+497118113608227@192.168.0.89:37260;transport=TLS out_uri=sip:+497118113608227@192.168.0.89:37260;transport Do you have any suggestions? Thank you very much in advance! Regards Andreas

1 0

[Kamailio-Users] Sip MESSAGE
by Abdul Hakeem 04 Feb '10

04 Feb '10

Hello, Does anyone knows if Kamalito supports MESSAGE method & where I can find the documentation or API's ? Regards, Abdul Hakeem

6 18

[Kamailio-Users] new module: mqueue
by Elena-Ramona Modroiu 04 Feb '10

04 Feb '10

Hi, few details about the new module mqueue. It provides a generic message queue for SIP Router inter process communication. Items in the queue are pairs of (key, value), both string. The items are consumed in the order they were added in the queue (first in first out). More details at: http://sip-router.org/docbook/sip-router/branch/master/modules/mqueue/mqueu… http://sip-router.org/wiki/cookbooks/pseudo-variables/devel#mqueue_module_p… The module is handy to use for time consuming and/or blocking operations (eg, email notifications). Not to hold the SIP worker process, you can add an item in a queue that is going to be consumed by another process (like timer processes created via rtimer module). Best regards, Ramona

1 0

[Kamailio-Users] [kamailio-users] can't connect with remote database
by Chandrakant Solanki 04 Feb '10

04 Feb '10

Hi I have 3 server with 172.16.0.10/13/14 IP address. My DB is located for 172.16.0.10. I tried to connect mysql from terminal, it works great. But when I start kamailio it gives me following error.. *kamailio.cfg* loadmodule "usrloc.so" ----- ----- ----- modparam("usrloc", "socket_column", "socket") modparam("usrloc", "use_domain", 0) modparam("usrloc", "desc_time_order", 0) modparam("usrloc", "timer_interval", 60) modparam("usrloc", "db_url", "mysql://openser:openserrw@172.16.0.10/openser ") *error.... *Feb 4 17:10:53 localhost /usr/local/sbin/kamailio[28792]: ERROR:core:db_do_init: could not add connection to the pool Feb 4 17:10:53 localhost /usr/local/sbin/kamailio[28792]: ERROR:usrloc:child_init: child(8): failed to connect to database Feb 4 17:10:53 localhost /usr/local/sbin/kamailio[28792]: ERROR:core:init_mod_child: failed to initializing module usrloc, rank 8 Feb 4 17:10:53 localhost /usr/local/sbin/kamailio[28792]: ERROR:core:main_loop: init_child failed for UDP listener Feb 4 17:10:53 localhost /usr/local/sbin/kamailio[28793]: ERROR:db_mysql:db_mysql_new_connection: driver error: Can't connect to MySQL server on '172.16.0.10' (4)* * -- Regards, Chandrakant Solanki

2 1

[Kamailio-Users] break a call?
by BERGANZ Francois 04 Feb '10

04 Feb '10

Hello, I know that we can break a call with sl_reply(). But, in the on_reply route, how can I break a call if I receive a 3XX (I cant use a sl_reply() function!) ? Thank you

2 2

[Kamailio-Users] xlog enhancements
by Elena-Ramona Modroiu 04 Feb '10

04 Feb '10

Hi, I added two new functions to xlog (modules_k): - xlogl(level, message) - xdbgl(message) They are similar to the existing functions, in addition they print the config line at the beginning of the message. The printed value is: "cfglineno:message" In this way you can spot easily in the logs where the function was used to print a particular message. http://sip-router.org/docbook/sip-router/branch/master/modules_k/xlog/xlog.… Regards, Ramona

3 5

[Kamailio-Users] Loose Route / Re-Invite
by Brandon Armstead 04 Feb '10

04 Feb '10

Hello everyone, I'm just curious as to see what some of you guys do in regards to handling a Re-Invite that comes back downstream to a NATTED UAC. For example, call scenario: UAC -> Kamailio (Fix Nated Contact) -> PSTN Re-Invite Occurs: PSTN -> Kamailio -> UAC UAC (200 OK w/ NAT RFC1918 contact) -> Kamailio (branch flags at this point are not notifying of NAT, due to the downstream direction of the INVITE, so RFC1918 address exists, but does not fix_nated_contact) -> PSTN PSTN does not appropriately ACK. So, what are your guys solutions for solving this problem? Is the best way to add an attribute onto the contact header sent in original INVITE? Are there other ways of handling? What is the best, cleanest method. Possible to handle with AVP's? Thanks in advanced for all of your input! Sincerely, Brandon

6 22

[Kamailio-Users] [OT] acabrera@sintys.gov.ar is away, did you know?
by Iñaki Baz Castillo 04 Feb '10

04 Feb '10

Hi, am I the only person receiving an auto-reply mail from acabrera(a)sintys.gov.ar with subject "Ausente" ("Away") for each mail sent to this list (and perhaps to others)? I've already sent him a direct mail. However, why do people use such auto- reply stuf in mail?? this is mail, an asynchronous communication, the receipt can read the mail whenever he prefers, not need to tell me "I'm away now". grrrr -- Iñaki Baz Castillo <ibc(a)aliax.net>

3 3

Re: [Kamailio-Users] Loose Route / Re-Invite (brandon@cryy.com)
by Brandon Armstead 03 Feb '10

03 Feb '10

Hello, Please refer to sip trace: http://pastebin.org/86010. On LINE 294, PSTN sends the Re-INVITE On LINE 378, REGISTRAR sends 200 OK to SIP SBC (with RFC 1918 Address, that is being relayed from the UAC that also sends this same address upon 200 OK of the Re-Invite). Let me know if this makes sense, this trace was taken on the SBC.

4 5

[Kamailio-Users] Registration delays when using Kamailio proxy
by Vikram Ragukumar 03 Feb '10

03 Feb '10

Hello, I am using an x-lite softphone to register with my SIP domain, (a) Without an outbound proxy - Registration is successful and takes about 3 seconds (b) With an outbound proxy - Registration is successful but takes nearly 15 seconds I briefly describe below the sequence of SIP messages while using the outbound proxy Register softphone -> proxy Register proxy -> SIP server Register softphone -> proxy 407 Proxy authentication reqd. SIP server -> proxy Register softphone -> proxy 407 Proxy authentication reqd. proxy -> softphone Register softphone -> proxy (With Digest response) Register proxy -> SIP server (With Digest response) 200 OK Sip server -> proxy Register softphone -> proxy (With Digest response) I am attaching a log with wireshark captures that show SIP messages exchanged between the SIP server,SIP proxy and the x-lite softphone. The log shows several messages being duplicated (REGISTER, 200 OK) 1) Why does the softphone continue to send REGISTER messages after receiving a 200 OK response ? (almost 15 repetitions of REGISTER after receiving 200 OK) 2) What is the reason for the delay in registration times with/without the proxy ? Thanks and Regards, Vikram. No. Time Source Destination Protocol Info 1 0.000000 ab.cde.fgh.ijx(xlite) ab.cde.fgh.ijk(proxy) SIP Request: REGISTER sip:lm.nop.qrs.tu(server) Frame 1 (611 bytes on wire, 611 bytes captured) Ethernet II, Src: 1a:1b:1c:1d:1e:1f (1a:1b:1c:1d:1e:1f), Dst: Supermic_bd:b9:bc (00:30:48:bd:b9:bc) Internet Protocol, Src: ab.cde.fgh.ijx(xlite) (ab.cde.fgh.ijx(xlite)), Dst: ab.cde.fgh.ijk(proxy) (ab.cde.fgh.ijk(proxy)) User Datagram Protocol, Src Port: 33374 (33374), Dst Port: sip (5060) Session Initiation Protocol Request-Line: REGISTER sip:lm.nop.qrs.tu(server) SIP/2.0 Message Header Via: SIP/2.0/UDP ab.cde.fgh.ijx(xlite):50648;branch=z9hG4bK-d8754z-c252300b156adb6c-1---d8754z-;rport Max-Forwards: 70 Contact: <sip:1234@ab.cde.fgh.ijx(xlite):50648;rinstance=0f34c912798e872d> To: "1234"<sip:1234@lm.nop.qrs.tu(server)> From: "1234"<sip:1234@lm.nop.qrs.tu(server)>;tag=cb57d146 Call-ID: Zjg5MTdhZjMyYTZlMzlmZTA2NjY4MDBhMjNhYjkyMDU. CSeq: 1 REGISTER Expires: 3600 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO User-Agent: X-Lite release 1104o stamp 56125 Content-Length: 0 3 0.839564 ab.cde.fgh.ijk(proxy) lm.nop.qrs.tu(server) SIP Request: REGISTER sip:lm.nop.qrs.tu(server) Frame 3 (722 bytes on wire, 722 bytes captured) Ethernet II, Src: Supermic_bd:b9:bc (00:30:48:bd:b9:bc), Dst: Unispher_40:b5:39 (00:90:1a:40:b5:39) Internet Protocol, Src: ab.cde.fgh.ijk(proxy) (ab.cde.fgh.ijk(proxy)), Dst: lm.nop.qrs.tu(server) (lm.nop.qrs.tu(server)) User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060) Session Initiation Protocol Request-Line: REGISTER sip:lm.nop.qrs.tu(server) SIP/2.0 Message Header Via: SIP/2.0/UDP ab.cde.fgh.ijk(proxy);branch=z9hG4bK31c8.d11a2c71.0 Via: SIP/2.0/UDP ab.cde.fgh.ijx(xlite):50648;received=ab.cde.fgh.ijx(xlite);branch=z9hG4bK-d8754z-c252300b156adb6c-1---d8754z-;rport=33374 Max-Forwards: 69 Contact: <sip:1234@ab.cde.fgh.ijx(xlite):50648;rinstance=0f34c912798e872d> To: "1234"<sip:1234@lm.nop.qrs.tu(server)> From: "1234"<sip:1234@lm.nop.qrs.tu(server)>;tag=cb57d146 Call-ID: Zjg5MTdhZjMyYTZlMzlmZTA2NjY4MDBhMjNhYjkyMDU. CSeq: 1 REGISTER Expires: 3600 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO User-Agent: X-Lite release 1104o stamp 56125 Content-Length: 0 P-hint: outbound No. Time Source Destination Protocol Info 4 0.952097 lm.nop.qrs.tu(server) ab.cde.fgh.ijk(proxy) SIP Status: 407 Proxy Authentication Required (0 bindings) Frame 4 (555 bytes on wire, 555 bytes captured) Ethernet II, Src: Unispher_40:b5:39 (00:90:1a:40:b5:39), Dst: Supermic_bd:b9:bc (00:30:48:bd:b9:bc) Internet Protocol, Src: lm.nop.qrs.tu(server) (lm.nop.qrs.tu(server)), Dst: ab.cde.fgh.ijk(proxy) (ab.cde.fgh.ijk(proxy)) User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060) Session Initiation Protocol Status-Line: SIP/2.0 407 Proxy Authentication Required Message Header CSeq: 1 REGISTER Via: SIP/2.0/UDP ab.cde.fgh.ijk(proxy);branch=z9hG4bK31c8.d11a2c71.0 Via: SIP/2.0/UDP ab.cde.fgh.ijx(xlite):50648;branch=z9hG4bK-d8754z-c252300b156adb6c-1---d8754z-;rport=33374 From: "1234"<sip:1234@lm.nop.qrs.tu(server)>;tag=cb57d146 Call-ID: Zjg5MTdhZjMyYTZlMzlmZTA2NjY4MDBhMjNhYjkyMDU. To: "1234"<sip:1234@lm.nop.qrs.tu(server)>;tag=030240100052 Proxy-Authenticate: DIGEST realm="VoipSwitch", nonce="126513605203001203402405205305" Content-Length: 0 No. Time Source Destination Protocol Info 5 1.404504 ab.cde.fgh.ijk(proxy) lm.nop.qrs.tu(server) SIP Request: REGISTER sip:lm.nop.qrs.tu(server) Frame 5 (722 bytes on wire, 722 bytes captured) Ethernet II, Src: Supermic_bd:b9:bc (00:30:48:bd:b9:bc), Dst: Unispher_40:b5:39 (00:90:1a:40:b5:39) Internet Protocol, Src: ab.cde.fgh.ijk(proxy) (ab.cde.fgh.ijk(proxy)), Dst: lm.nop.qrs.tu(server) (lm.nop.qrs.tu(server)) User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060) Session Initiation Protocol Request-Line: REGISTER sip:lm.nop.qrs.tu(server) SIP/2.0 Message Header Via: SIP/2.0/UDP ab.cde.fgh.ijk(proxy);branch=z9hG4bK31c8.d11a2c71.0 Via: SIP/2.0/UDP ab.cde.fgh.ijx(xlite):50648;received=ab.cde.fgh.ijx(xlite);branch=z9hG4bK-d8754z-c252300b156adb6c-1---d8754z-;rport=33374 Max-Forwards: 69 Contact: <sip:1234@ab.cde.fgh.ijx(xlite):50648;rinstance=0f34c912798e872d> To: "1234"<sip:1234@lm.nop.qrs.tu(server)> From: "1234"<sip:1234@lm.nop.qrs.tu(server)>;tag=cb57d146 Call-ID: Zjg5MTdhZjMyYTZlMzlmZTA2NjY4MDBhMjNhYjkyMDU. CSeq: 1 REGISTER Expires: 3600 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO User-Agent: X-Lite release 1104o stamp 56125 Content-Length: 0 P-hint: outbound No. Time Source Destination Protocol Info 6 1.517292 lm.nop.qrs.tu(server) ab.cde.fgh.ijk(proxy) SIP Status: 407 Proxy Authentication Required (0 bindings) Frame 6 (555 bytes on wire, 555 bytes captured) Ethernet II, Src: Unispher_40:b5:39 (00:90:1a:40:b5:39), Dst: Supermic_bd:b9:bc (00:30:48:bd:b9:bc) Internet Protocol, Src: lm.nop.qrs.tu(server) (lm.nop.qrs.tu(server)), Dst: ab.cde.fgh.ijk(proxy) (ab.cde.fgh.ijk(proxy)) User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060) Session Initiation Protocol Status-Line: SIP/2.0 407 Proxy Authentication Required Message Header CSeq: 1 REGISTER Via: SIP/2.0/UDP ab.cde.fgh.ijk(proxy);branch=z9hG4bK31c8.d11a2c71.0 Via: SIP/2.0/UDP ab.cde.fgh.ijx(xlite):50648;branch=z9hG4bK-d8754z-c252300b156adb6c-1---d8754z-;rport=33374 From: "1234"<sip:1234@lm.nop.qrs.tu(server)>;tag=cb57d146 Call-ID: Zjg5MTdhZjMyYTZlMzlmZTA2NjY4MDBhMjNhYjkyMDU. To: "1234"<sip:1234@lm.nop.qrs.tu(server)>;tag=030240100053 Proxy-Authenticate: DIGEST realm="VoipSwitch", nonce="126513605303001203402405305305" Content-Length: 0 No. Time Source Destination Protocol Info 7 1.522829 ab.cde.fgh.ijx(xlite) ab.cde.fgh.ijk(proxy) SIP Request: REGISTER sip:lm.nop.qrs.tu(server) Frame 7 (611 bytes on wire, 611 bytes captured) Ethernet II, Src: 1a:1b:1c:1d:1e:1f (1a:1b:1c:1d:1e:1f), Dst: Supermic_bd:b9:bc (00:30:48:bd:b9:bc) Internet Protocol, Src: ab.cde.fgh.ijx(xlite) (ab.cde.fgh.ijx(xlite)), Dst: ab.cde.fgh.ijk(proxy) (ab.cde.fgh.ijk(proxy)) User Datagram Protocol, Src Port: 33374 (33374), Dst Port: sip (5060) Session Initiation Protocol Request-Line: REGISTER sip:lm.nop.qrs.tu(server) SIP/2.0 Message Header Via: SIP/2.0/UDP ab.cde.fgh.ijx(xlite):50648;branch=z9hG4bK-d8754z-c252300b156adb6c-1---d8754z-;rport Max-Forwards: 70 Contact: <sip:1234@ab.cde.fgh.ijx(xlite):50648;rinstance=0f34c912798e872d> To: "1234"<sip:1234@lm.nop.qrs.tu(server)> From: "1234"<sip:1234@lm.nop.qrs.tu(server)>;tag=cb57d146 Call-ID: Zjg5MTdhZjMyYTZlMzlmZTA2NjY4MDBhMjNhYjkyMDU. CSeq: 1 REGISTER Expires: 3600 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO User-Agent: X-Lite release 1104o stamp 56125 Content-Length: 0 No. Time Source Destination Protocol Info 8 2.522300 ab.cde.fgh.ijk(proxy) ab.cde.fgh.ijx(xlite) SIP Status: 407 Proxy Authentication Required (0 bindings) Frame 8 (492 bytes on wire, 492 bytes captured) Ethernet II, Src: Supermic_bd:b9:bc (00:30:48:bd:b9:bc), Dst: 1a:1b:1c:1d:1e:1f (1a:1b:1c:1d:1e:1f) Internet Protocol, Src: ab.cde.fgh.ijk(proxy) (ab.cde.fgh.ijk(proxy)), Dst: ab.cde.fgh.ijx(xlite) (ab.cde.fgh.ijx(xlite)) User Datagram Protocol, Src Port: sip (5060), Dst Port: 33374 (33374) Session Initiation Protocol Status-Line: SIP/2.0 407 Proxy Authentication Required Message Header CSeq: 1 REGISTER Via: SIP/2.0/UDP ab.cde.fgh.ijx(xlite):50648;branch=z9hG4bK-d8754z-c252300b156adb6c-1---d8754z-;rport=33374 From: "1234"<sip:1234@lm.nop.qrs.tu(server)>;tag=cb57d146 Call-ID: Zjg5MTdhZjMyYTZlMzlmZTA2NjY4MDBhMjNhYjkyMDU. To: "1234"<sip:1234@lm.nop.qrs.tu(server)>;tag=030240100052 Proxy-Authenticate: DIGEST realm="VoipSwitch", nonce="126513605203001203402405205305" Content-Length: 0 No. Time Source Destination Protocol Info 9 2.730896 ab.cde.fgh.ijx(xlite) ab.cde.fgh.ijk(proxy) SIP Request: REGISTER sip:lm.nop.qrs.tu(server) Frame 9 (801 bytes on wire, 801 bytes captured) Ethernet II, Src: 1a:1b:1c:1d:1e:1f (1a:1b:1c:1d:1e:1f), Dst: Supermic_bd:b9:bc (00:30:48:bd:b9:bc) Internet Protocol, Src: ab.cde.fgh.ijx(xlite) (ab.cde.fgh.ijx(xlite)), Dst: ab.cde.fgh.ijk(proxy) (ab.cde.fgh.ijk(proxy)) User Datagram Protocol, Src Port: 33374 (33374), Dst Port: sip (5060) Session Initiation Protocol Request-Line: REGISTER sip:lm.nop.qrs.tu(server) SIP/2.0 Message Header Via: SIP/2.0/UDP ab.cde.fgh.ijx(xlite):50648;branch=z9hG4bK-d8754z-4248775550708257-1---d8754z-;rport Max-Forwards: 70 Contact: <sip:1234@ab.cde.fgh.ijx(xlite):50648;rinstance=0f34c912798e872d> To: "1234"<sip:1234@lm.nop.qrs.tu(server)> From: "1234"<sip:1234@lm.nop.qrs.tu(server)>;tag=cb57d146 Call-ID: Zjg5MTdhZjMyYTZlMzlmZTA2NjY4MDBhMjNhYjkyMDU. CSeq: 2 REGISTER Expires: 3600 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Proxy-Authorization: Digest username="1234",realm="VoipSwitch",nonce="126513605203001203402405205305",uri="sip:lm.nop.qrs.tu(server)",response="2c0d7d2f3b4cc218792ebef30e0eb2e6",algorithm=MD5 User-Agent: X-Lite release 1104o stamp 56125 Content-Length: 0 No. Time Source Destination Protocol Info 10 2.796109 ab.cde.fgh.ijk(proxy) ab.cde.fgh.ijx(xlite) SIP Status: 407 Proxy Authentication Required (0 bindings) Frame 10 (492 bytes on wire, 492 bytes captured) Ethernet II, Src: Supermic_bd:b9:bc (00:30:48:bd:b9:bc), Dst: 1a:1b:1c:1d:1e:1f (1a:1b:1c:1d:1e:1f) Internet Protocol, Src: ab.cde.fgh.ijk(proxy) (ab.cde.fgh.ijk(proxy)), Dst: ab.cde.fgh.ijx(xlite) (ab.cde.fgh.ijx(xlite)) User Datagram Protocol, Src Port: sip (5060), Dst Port: 33374 (33374) Session Initiation Protocol Status-Line: SIP/2.0 407 Proxy Authentication Required Message Header CSeq: 1 REGISTER Via: SIP/2.0/UDP ab.cde.fgh.ijx(xlite):50648;branch=z9hG4bK-d8754z-c252300b156adb6c-1---d8754z-;rport=33374 From: "1234"<sip:1234@lm.nop.qrs.tu(server)>;tag=cb57d146 Call-ID: Zjg5MTdhZjMyYTZlMzlmZTA2NjY4MDBhMjNhYjkyMDU. To: "1234"<sip:1234@lm.nop.qrs.tu(server)>;tag=030240100052 Proxy-Authenticate: DIGEST realm="VoipSwitch", nonce="126513605203001203402405205305" Content-Length: 0 No. Time Source Destination Protocol Info 11 3.308767 ab.cde.fgh.ijx(xlite) ab.cde.fgh.ijk(proxy) SIP Request: REGISTER sip:lm.nop.qrs.tu(server) Frame 11 (801 bytes on wire, 801 bytes captured) Ethernet II, Src: 1a:1b:1c:1d:1e:1f (1a:1b:1c:1d:1e:1f), Dst: Supermic_bd:b9:bc (00:30:48:bd:b9:bc) Internet Protocol, Src: ab.cde.fgh.ijx(xlite) (ab.cde.fgh.ijx(xlite)), Dst: ab.cde.fgh.ijk(proxy) (ab.cde.fgh.ijk(proxy)) User Datagram Protocol, Src Port: 33374 (33374), Dst Port: sip (5060) Session Initiation Protocol Request-Line: REGISTER sip:lm.nop.qrs.tu(server) SIP/2.0 Message Header Via: SIP/2.0/UDP ab.cde.fgh.ijx(xlite):50648;branch=z9hG4bK-d8754z-4248775550708257-1---d8754z-;rport Max-Forwards: 70 Contact: <sip:1234@ab.cde.fgh.ijx(xlite):50648;rinstance=0f34c912798e872d> To: "1234"<sip:1234@lm.nop.qrs.tu(server)> From: "1234"<sip:1234@lm.nop.qrs.tu(server)>;tag=cb57d146 Call-ID: Zjg5MTdhZjMyYTZlMzlmZTA2NjY4MDBhMjNhYjkyMDU. CSeq: 2 REGISTER Expires: 3600 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Proxy-Authorization: Digest username="1234",realm="VoipSwitch",nonce="126513605203001203402405205305",uri="sip:lm.nop.qrs.tu(server)",response="2c0d7d2f3b4cc218792ebef30e0eb2e6",algorithm=MD5 User-Agent: X-Lite release 1104o stamp 56125 Content-Length: 0 No. Time Source Destination Protocol Info 12 4.099907 ab.cde.fgh.ijk(proxy) lm.nop.qrs.tu(server) SIP Request: REGISTER sip:lm.nop.qrs.tu(server) Frame 12 (912 bytes on wire, 912 bytes captured) Ethernet II, Src: Supermic_bd:b9:bc (00:30:48:bd:b9:bc), Dst: Unispher_40:b5:39 (00:90:1a:40:b5:39) Internet Protocol, Src: ab.cde.fgh.ijk(proxy) (ab.cde.fgh.ijk(proxy)), Dst: lm.nop.qrs.tu(server) (lm.nop.qrs.tu(server)) User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060) Session Initiation Protocol Request-Line: REGISTER sip:lm.nop.qrs.tu(server) SIP/2.0 Message Header Via: SIP/2.0/UDP ab.cde.fgh.ijk(proxy);branch=z9hG4bK01c8.2e6fe072.0 Via: SIP/2.0/UDP ab.cde.fgh.ijx(xlite):50648;received=ab.cde.fgh.ijx(xlite);branch=z9hG4bK-d8754z-4248775550708257-1---d8754z-;rport=33374 Max-Forwards: 69 Contact: <sip:1234@ab.cde.fgh.ijx(xlite):50648;rinstance=0f34c912798e872d> To: "1234"<sip:1234@lm.nop.qrs.tu(server)> From: "1234"<sip:1234@lm.nop.qrs.tu(server)>;tag=cb57d146 Call-ID: Zjg5MTdhZjMyYTZlMzlmZTA2NjY4MDBhMjNhYjkyMDU. CSeq: 2 REGISTER Expires: 3600 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Proxy-Authorization: Digest username="1234",realm="VoipSwitch",nonce="126513605203001203402405205305",uri="sip:lm.nop.qrs.tu(server)",response="2c0d7d2f3b4cc218792ebef30e0eb2e6",algorithm=MD5 User-Agent: X-Lite release 1104o stamp 56125 Content-Length: 0 P-hint: outbound No. Time Source Destination Protocol Info 13 4.216914 lm.nop.qrs.tu(server) ab.cde.fgh.ijk(proxy) SIP Status: 407 Proxy Authentication Required (0 bindings) Frame 13 (555 bytes on wire, 555 bytes captured) Ethernet II, Src: Unispher_40:b5:39 (00:90:1a:40:b5:39), Dst: Supermic_bd:b9:bc (00:30:48:bd:b9:bc) Internet Protocol, Src: lm.nop.qrs.tu(server) (lm.nop.qrs.tu(server)), Dst: ab.cde.fgh.ijk(proxy) (ab.cde.fgh.ijk(proxy)) User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060) Session Initiation Protocol Status-Line: SIP/2.0 407 Proxy Authentication Required Message Header CSeq: 2 REGISTER Via: SIP/2.0/UDP ab.cde.fgh.ijk(proxy);branch=z9hG4bK01c8.2e6fe072.0 Via: SIP/2.0/UDP ab.cde.fgh.ijx(xlite):50648;branch=z9hG4bK-d8754z-4248775550708257-1---d8754z-;rport=33374 From: "1234"<sip:1234@lm.nop.qrs.tu(server)>;tag=cb57d146 Call-ID: Zjg5MTdhZjMyYTZlMzlmZTA2NjY4MDBhMjNhYjkyMDU. To: "1234"<sip:1234@lm.nop.qrs.tu(server)>;tag=030240100055 Proxy-Authenticate: DIGEST realm="VoipSwitch", nonce="126513605503001203402405505305" Content-Length: 0 No. Time Source Destination Protocol Info 14 4.324392 ab.cde.fgh.ijx(xlite) ab.cde.fgh.ijk(proxy) SIP Request: REGISTER sip:lm.nop.qrs.tu(server) Frame 14 (801 bytes on wire, 801 bytes captured) Ethernet II, Src: 1a:1b:1c:1d:1e:1f (1a:1b:1c:1d:1e:1f), Dst: Supermic_bd:b9:bc (00:30:48:bd:b9:bc) Internet Protocol, Src: ab.cde.fgh.ijx(xlite) (ab.cde.fgh.ijx(xlite)), Dst: ab.cde.fgh.ijk(proxy) (ab.cde.fgh.ijk(proxy)) User Datagram Protocol, Src Port: 33374 (33374), Dst Port: sip (5060) Session Initiation Protocol Request-Line: REGISTER sip:lm.nop.qrs.tu(server) SIP/2.0 Message Header Via: SIP/2.0/UDP ab.cde.fgh.ijx(xlite):50648;branch=z9hG4bK-d8754z-4248775550708257-1---d8754z-;rport Max-Forwards: 70 Contact: <sip:1234@ab.cde.fgh.ijx(xlite):50648;rinstance=0f34c912798e872d> To: "1234"<sip:1234@lm.nop.qrs.tu(server)> From: "1234"<sip:1234@lm.nop.qrs.tu(server)>;tag=cb57d146 Call-ID: Zjg5MTdhZjMyYTZlMzlmZTA2NjY4MDBhMjNhYjkyMDU. CSeq: 2 REGISTER Expires: 3600 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Proxy-Authorization: Digest username="1234",realm="VoipSwitch",nonce="126513605203001203402405205305",uri="sip:lm.nop.qrs.tu(server)",response="2c0d7d2f3b4cc218792ebef30e0eb2e6",algorithm=MD5 User-Agent: X-Lite release 1104o stamp 56125 Content-Length: 0 No. Time Source Destination Protocol Info 15 4.704708 ab.cde.fgh.ijk(proxy) lm.nop.qrs.tu(server) SIP Request: REGISTER sip:lm.nop.qrs.tu(server) Frame 15 (912 bytes on wire, 912 bytes captured) Ethernet II, Src: Supermic_bd:b9:bc (00:30:48:bd:b9:bc), Dst: Unispher_40:b5:39 (00:90:1a:40:b5:39) Internet Protocol, Src: ab.cde.fgh.ijk(proxy) (ab.cde.fgh.ijk(proxy)), Dst: lm.nop.qrs.tu(server) (lm.nop.qrs.tu(server)) User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060) Session Initiation Protocol Request-Line: REGISTER sip:lm.nop.qrs.tu(server) SIP/2.0 Message Header Via: SIP/2.0/UDP ab.cde.fgh.ijk(proxy);branch=z9hG4bK01c8.2e6fe072.0 Via: SIP/2.0/UDP ab.cde.fgh.ijx(xlite):50648;received=ab.cde.fgh.ijx(xlite);branch=z9hG4bK-d8754z-4248775550708257-1---d8754z-;rport=33374 Max-Forwards: 69 Contact: <sip:1234@ab.cde.fgh.ijx(xlite):50648;rinstance=0f34c912798e872d> To: "1234"<sip:1234@lm.nop.qrs.tu(server)> From: "1234"<sip:1234@lm.nop.qrs.tu(server)>;tag=cb57d146 Call-ID: Zjg5MTdhZjMyYTZlMzlmZTA2NjY4MDBhMjNhYjkyMDU. CSeq: 2 REGISTER Expires: 3600 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Proxy-Authorization: Digest username="1234",realm="VoipSwitch",nonce="126513605203001203402405205305",uri="sip:lm.nop.qrs.tu(server)",response="2c0d7d2f3b4cc218792ebef30e0eb2e6",algorithm=MD5 User-Agent: X-Lite release 1104o stamp 56125 Content-Length: 0 P-hint: outbound No. Time Source Destination Protocol Info 16 4.822244 lm.nop.qrs.tu(server) ab.cde.fgh.ijk(proxy) SIP Status: 407 Proxy Authentication Required (0 bindings) Frame 16 (555 bytes on wire, 555 bytes captured) Ethernet II, Src: Unispher_40:b5:39 (00:90:1a:40:b5:39), Dst: Supermic_bd:b9:bc (00:30:48:bd:b9:bc) Internet Protocol, Src: lm.nop.qrs.tu(server) (lm.nop.qrs.tu(server)), Dst: ab.cde.fgh.ijk(proxy) (ab.cde.fgh.ijk(proxy)) User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060) Session Initiation Protocol Status-Line: SIP/2.0 407 Proxy Authentication Required Message Header CSeq: 2 REGISTER Via: SIP/2.0/UDP ab.cde.fgh.ijk(proxy);branch=z9hG4bK01c8.2e6fe072.0 Via: SIP/2.0/UDP ab.cde.fgh.ijx(xlite):50648;branch=z9hG4bK-d8754z-4248775550708257-1---d8754z-;rport=33374 From: "1234"<sip:1234@lm.nop.qrs.tu(server)>;tag=cb57d146 Call-ID: Zjg5MTdhZjMyYTZlMzlmZTA2NjY4MDBhMjNhYjkyMDU. To: "1234"<sip:1234@lm.nop.qrs.tu(server)>;tag=030240100056 Proxy-Authenticate: DIGEST realm="VoipSwitch", nonce="126513605603001203402405605305" Content-Length: 0 No. Time Source Destination Protocol Info 17 5.710292 ab.cde.fgh.ijk(proxy) ab.cde.fgh.ijx(xlite) SIP Status: 407 Proxy Authentication Required (0 bindings) Frame 17 (492 bytes on wire, 492 bytes captured) Ethernet II, Src: Supermic_bd:b9:bc (00:30:48:bd:b9:bc), Dst: 1a:1b:1c:1d:1e:1f (1a:1b:1c:1d:1e:1f) Internet Protocol, Src: ab.cde.fgh.ijk(proxy) (ab.cde.fgh.ijk(proxy)), Dst: ab.cde.fgh.ijx(xlite) (ab.cde.fgh.ijx(xlite)) User Datagram Protocol, Src Port: sip (5060), Dst Port: 33374 (33374) Session Initiation Protocol Status-Line: SIP/2.0 407 Proxy Authentication Required Message Header CSeq: 2 REGISTER Via: SIP/2.0/UDP ab.cde.fgh.ijx(xlite):50648;branch=z9hG4bK-d8754z-4248775550708257-1---d8754z-;rport=33374 From: "1234"<sip:1234@lm.nop.qrs.tu(server)>;tag=cb57d146 Call-ID: Zjg5MTdhZjMyYTZlMzlmZTA2NjY4MDBhMjNhYjkyMDU. To: "1234"<sip:1234@lm.nop.qrs.tu(server)>;tag=030240100055 Proxy-Authenticate: DIGEST realm="VoipSwitch", nonce="126513605503001203402405505305" Content-Length: 0 No. Time Source Destination Protocol Info 18 5.724689 ab.cde.fgh.ijk(proxy) ab.cde.fgh.ijx(xlite) SIP Status: 407 Proxy Authentication Required (0 bindings) Frame 18 (492 bytes on wire, 492 bytes captured) Ethernet II, Src: Supermic_bd:b9:bc (00:30:48:bd:b9:bc), Dst: 1a:1b:1c:1d:1e:1f (1a:1b:1c:1d:1e:1f) Internet Protocol, Src: ab.cde.fgh.ijk(proxy) (ab.cde.fgh.ijk(proxy)), Dst: ab.cde.fgh.ijx(xlite) (ab.cde.fgh.ijx(xlite)) User Datagram Protocol, Src Port: sip (5060), Dst Port: 33374 (33374) Session Initiation Protocol Status-Line: SIP/2.0 407 Proxy Authentication Required Message Header CSeq: 2 REGISTER Via: SIP/2.0/UDP ab.cde.fgh.ijx(xlite):50648;branch=z9hG4bK-d8754z-4248775550708257-1---d8754z-;rport=33374 From: "1234"<sip:1234@lm.nop.qrs.tu(server)>;tag=cb57d146 Call-ID: Zjg5MTdhZjMyYTZlMzlmZTA2NjY4MDBhMjNhYjkyMDU. To: "1234"<sip:1234@lm.nop.qrs.tu(server)>;tag=030240100055 Proxy-Authenticate: DIGEST realm="VoipSwitch", nonce="126513605503001203402405505305" Content-Length: 0 No. Time Source Destination Protocol Info 19 5.832474 ab.cde.fgh.ijx(xlite) ab.cde.fgh.ijk(proxy) SIP Request: REGISTER sip:lm.nop.qrs.tu(server) Frame 19 (801 bytes on wire, 801 bytes captured) Ethernet II, Src: 1a:1b:1c:1d:1e:1f (1a:1b:1c:1d:1e:1f), Dst: Supermic_bd:b9:bc (00:30:48:bd:b9:bc) Internet Protocol, Src: ab.cde.fgh.ijx(xlite) (ab.cde.fgh.ijx(xlite)), Dst: ab.cde.fgh.ijk(proxy) (ab.cde.fgh.ijk(proxy)) User Datagram Protocol, Src Port: 33374 (33374), Dst Port: sip (5060) Session Initiation Protocol Request-Line: REGISTER sip:lm.nop.qrs.tu(server) SIP/2.0 Message Header Via: SIP/2.0/UDP ab.cde.fgh.ijx(xlite):50648;branch=z9hG4bK-d8754z-316786162159173a-1---d8754z-;rport Max-Forwards: 70 Contact: <sip:1234@ab.cde.fgh.ijx(xlite):50648;rinstance=0f34c912798e872d> To: "1234"<sip:1234@lm.nop.qrs.tu(server)> From: "1234"<sip:1234@lm.nop.qrs.tu(server)>;tag=cb57d146 Call-ID: Zjg5MTdhZjMyYTZlMzlmZTA2NjY4MDBhMjNhYjkyMDU. CSeq: 3 REGISTER Expires: 3600 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Proxy-Authorization: Digest username="1234",realm="VoipSwitch",nonce="126513605503001203402405505305",uri="sip:lm.nop.qrs.tu(server)",response="014a8ffc9e6cc551acc86b22f2c26c11",algorithm=MD5 User-Agent: X-Lite release 1104o stamp 56125 Content-Length: 0 No. Time Source Destination Protocol Info 21 7.455368 ab.cde.fgh.ijk(proxy) lm.nop.qrs.tu(server) SIP Request: REGISTER sip:lm.nop.qrs.tu(server) Frame 21 (912 bytes on wire, 912 bytes captured) Ethernet II, Src: Supermic_bd:b9:bc (00:30:48:bd:b9:bc), Dst: Unispher_40:b5:39 (00:90:1a:40:b5:39) Internet Protocol, Src: ab.cde.fgh.ijk(proxy) (ab.cde.fgh.ijk(proxy)), Dst: lm.nop.qrs.tu(server) (lm.nop.qrs.tu(server)) User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060) Session Initiation Protocol Request-Line: REGISTER sip:lm.nop.qrs.tu(server) SIP/2.0 Message Header Via: SIP/2.0/UDP ab.cde.fgh.ijk(proxy);branch=z9hG4bK11c8.7f536395.0 Via: SIP/2.0/UDP ab.cde.fgh.ijx(xlite):50648;received=ab.cde.fgh.ijx(xlite);branch=z9hG4bK-d8754z-316786162159173a-1---d8754z-;rport=33374 Max-Forwards: 69 Contact: <sip:1234@ab.cde.fgh.ijx(xlite):50648;rinstance=0f34c912798e872d> To: "1234"<sip:1234@lm.nop.qrs.tu(server)> From: "1234"<sip:1234@lm.nop.qrs.tu(server)>;tag=cb57d146 Call-ID: Zjg5MTdhZjMyYTZlMzlmZTA2NjY4MDBhMjNhYjkyMDU. CSeq: 3 REGISTER Expires: 3600 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Proxy-Authorization: Digest username="1234",realm="VoipSwitch",nonce="126513605503001203402405505305",uri="sip:lm.nop.qrs.tu(server)",response="014a8ffc9e6cc551acc86b22f2c26c11",algorithm=MD5 User-Agent: X-Lite release 1104o stamp 56125 Content-Length: 0 P-hint: outbound No. Time Source Destination Protocol Info 22 7.457267 ab.cde.fgh.ijx(xlite) ab.cde.fgh.ijk(proxy) SIP Request: REGISTER sip:lm.nop.qrs.tu(server) Frame 22 (801 bytes on wire, 801 bytes captured) Ethernet II, Src: 1a:1b:1c:1d:1e:1f (1a:1b:1c:1d:1e:1f), Dst: Supermic_bd:b9:bc (00:30:48:bd:b9:bc) Internet Protocol, Src: ab.cde.fgh.ijx(xlite) (ab.cde.fgh.ijx(xlite)), Dst: ab.cde.fgh.ijk(proxy) (ab.cde.fgh.ijk(proxy)) User Datagram Protocol, Src Port: 33374 (33374), Dst Port: sip (5060) Session Initiation Protocol Request-Line: REGISTER sip:lm.nop.qrs.tu(server) SIP/2.0 Message Header Via: SIP/2.0/UDP ab.cde.fgh.ijx(xlite):50648;branch=z9hG4bK-d8754z-316786162159173a-1---d8754z-;rport Max-Forwards: 70 Contact: <sip:1234@ab.cde.fgh.ijx(xlite):50648;rinstance=0f34c912798e872d> To: "1234"<sip:1234@lm.nop.qrs.tu(server)> From: "1234"<sip:1234@lm.nop.qrs.tu(server)>;tag=cb57d146 Call-ID: Zjg5MTdhZjMyYTZlMzlmZTA2NjY4MDBhMjNhYjkyMDU. CSeq: 3 REGISTER Expires: 3600 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Proxy-Authorization: Digest username="1234",realm="VoipSwitch",nonce="126513605503001203402405505305",uri="sip:lm.nop.qrs.tu(server)",response="014a8ffc9e6cc551acc86b22f2c26c11",algorithm=MD5 User-Agent: X-Lite release 1104o stamp 56125 Content-Length: 0 No. Time Source Destination Protocol Info 23 7.574533 lm.nop.qrs.tu(server) ab.cde.fgh.ijk(proxy) SIP Status: 200 OK (1 bindings) Frame 23 (539 bytes on wire, 539 bytes captured) Ethernet II, Src: Unispher_40:b5:39 (00:90:1a:40:b5:39), Dst: Supermic_bd:b9:bc (00:30:48:bd:b9:bc) Internet Protocol, Src: lm.nop.qrs.tu(server) (lm.nop.qrs.tu(server)), Dst: ab.cde.fgh.ijk(proxy) (ab.cde.fgh.ijk(proxy)) User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060) Session Initiation Protocol Status-Line: SIP/2.0 200 OK Message Header CSeq: 3 REGISTER Via: SIP/2.0/UDP ab.cde.fgh.ijk(proxy);branch=z9hG4bK11c8.7f536395.0 Via: SIP/2.0/UDP ab.cde.fgh.ijx(xlite):50648;branch=z9hG4bK-d8754z-316786162159173a-1---d8754z-;rport=33374 From: "1234"<sip:1234@lm.nop.qrs.tu(server)>;tag=cb57d146 Call-ID: Zjg5MTdhZjMyYTZlMzlmZTA2NjY4MDBhMjNhYjkyMDU. To: "1234"<sip:1234@lm.nop.qrs.tu(server)>;tag=030240100059 Contact: <sip:1234@ab.cde.fgh.ijx(xlite):50648;rinstance=0f34c912798e872d>;expires=60 Expires: 60 Content-Length: 0 No. Time Source Destination Protocol Info 24 8.355247 ab.cde.fgh.ijk(proxy) lm.nop.qrs.tu(server) SIP Request: REGISTER sip:lm.nop.qrs.tu(server) Frame 24 (912 bytes on wire, 912 bytes captured) Ethernet II, Src: Supermic_bd:b9:bc (00:30:48:bd:b9:bc), Dst: Unispher_40:b5:39 (00:90:1a:40:b5:39) Internet Protocol, Src: ab.cde.fgh.ijk(proxy) (ab.cde.fgh.ijk(proxy)), Dst: lm.nop.qrs.tu(server) (lm.nop.qrs.tu(server)) User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060) Session Initiation Protocol Request-Line: REGISTER sip:lm.nop.qrs.tu(server) SIP/2.0 Message Header Via: SIP/2.0/UDP ab.cde.fgh.ijk(proxy);branch=z9hG4bK11c8.7f536395.0 Via: SIP/2.0/UDP ab.cde.fgh.ijx(xlite):50648;received=ab.cde.fgh.ijx(xlite);branch=z9hG4bK-d8754z-316786162159173a-1---d8754z-;rport=33374 Max-Forwards: 69 Contact: <sip:1234@ab.cde.fgh.ijx(xlite):50648;rinstance=0f34c912798e872d> To: "1234"<sip:1234@lm.nop.qrs.tu(server)> From: "1234"<sip:1234@lm.nop.qrs.tu(server)>;tag=cb57d146 Call-ID: Zjg5MTdhZjMyYTZlMzlmZTA2NjY4MDBhMjNhYjkyMDU. CSeq: 3 REGISTER Expires: 3600 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Proxy-Authorization: Digest username="1234",realm="VoipSwitch",nonce="126513605503001203402405505305",uri="sip:lm.nop.qrs.tu(server)",response="014a8ffc9e6cc551acc86b22f2c26c11",algorithm=MD5 User-Agent: X-Lite release 1104o stamp 56125 Content-Length: 0 P-hint: outbound No. Time Source Destination Protocol Info 25 8.472891 lm.nop.qrs.tu(server) ab.cde.fgh.ijk(proxy) SIP Status: 200 OK (1 bindings) Frame 25 (539 bytes on wire, 539 bytes captured) Ethernet II, Src: Unispher_40:b5:39 (00:90:1a:40:b5:39), Dst: Supermic_bd:b9:bc (00:30:48:bd:b9:bc) Internet Protocol, Src: lm.nop.qrs.tu(server) (lm.nop.qrs.tu(server)), Dst: ab.cde.fgh.ijk(proxy) (ab.cde.fgh.ijk(proxy)) User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060) Session Initiation Protocol Status-Line: SIP/2.0 200 OK Message Header CSeq: 3 REGISTER Via: SIP/2.0/UDP ab.cde.fgh.ijk(proxy);branch=z9hG4bK11c8.7f536395.0 Via: SIP/2.0/UDP ab.cde.fgh.ijx(xlite):50648;branch=z9hG4bK-d8754z-316786162159173a-1---d8754z-;rport=33374 From: "1234"<sip:1234@lm.nop.qrs.tu(server)>;tag=cb57d146 Call-ID: Zjg5MTdhZjMyYTZlMzlmZTA2NjY4MDBhMjNhYjkyMDU. To: "1234"<sip:1234@lm.nop.qrs.tu(server)>;tag=030241100000 Contact: <sip:1234@ab.cde.fgh.ijx(xlite):50648;rinstance=0f34c912798e872d>;expires=60 Expires: 60 Content-Length: 0 No. Time Source Destination Protocol Info 26 9.310268 ab.cde.fgh.ijk(proxy) ab.cde.fgh.ijx(xlite) SIP Status: 200 OK (1 bindings) Frame 26 (476 bytes on wire, 476 bytes captured) Ethernet II, Src: Supermic_bd:b9:bc (00:30:48:bd:b9:bc), Dst: 1a:1b:1c:1d:1e:1f (1a:1b:1c:1d:1e:1f) Internet Protocol, Src: ab.cde.fgh.ijk(proxy) (ab.cde.fgh.ijk(proxy)), Dst: ab.cde.fgh.ijx(xlite) (ab.cde.fgh.ijx(xlite)) User Datagram Protocol, Src Port: sip (5060), Dst Port: 33374 (33374) Session Initiation Protocol Status-Line: SIP/2.0 200 OK Message Header CSeq: 3 REGISTER Via: SIP/2.0/UDP ab.cde.fgh.ijx(xlite):50648;branch=z9hG4bK-d8754z-316786162159173a-1---d8754z-;rport=33374 From: "1234"<sip:1234@lm.nop.qrs.tu(server)>;tag=cb57d146 Call-ID: Zjg5MTdhZjMyYTZlMzlmZTA2NjY4MDBhMjNhYjkyMDU. To: "1234"<sip:1234@lm.nop.qrs.tu(server)>;tag=030240100059 Contact: <sip:1234@ab.cde.fgh.ijx(xlite):50648;rinstance=0f34c912798e872d>;expires=60 Expires: 60 Content-Length: 0 No. Time Source Destination Protocol Info 29 10.939788 ab.cde.fgh.ijx(xlite) ab.cde.fgh.ijk(proxy) SIP Request: REGISTER sip:lm.nop.qrs.tu(server) Frame 29 (796 bytes on wire, 796 bytes captured) Ethernet II, Src: 1a:1b:1c:1d:1e:1f (1a:1b:1c:1d:1e:1f), Dst: Supermic_bd:b9:bc (00:30:48:bd:b9:bc) Internet Protocol, Src: ab.cde.fgh.ijx(xlite) (ab.cde.fgh.ijx(xlite)), Dst: ab.cde.fgh.ijk(proxy) (ab.cde.fgh.ijk(proxy)) User Datagram Protocol, Src Port: 33374 (33374), Dst Port: sip (5060) Session Initiation Protocol Request-Line: REGISTER sip:lm.nop.qrs.tu(server) SIP/2.0 Message Header Via: SIP/2.0/UDP ab.cde.fgh.ijx(xlite):50648;branch=z9hG4bK-d8754z-075267174a75f03a-1---d8754z-;rport Max-Forwards: 70 Contact: <sip:1234@ab.cde.fgh.ijx(xlite):50648;rinstance=0f34c912798e872d>;expires=0 To: "1234"<sip:1234@lm.nop.qrs.tu(server)> From: "1234"<sip:1234@lm.nop.qrs.tu(server)>;tag=cb57d146 Call-ID: Zjg5MTdhZjMyYTZlMzlmZTA2NjY4MDBhMjNhYjkyMDU. CSeq: 4 REGISTER Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Proxy-Authorization: Digest username="1234",realm="VoipSwitch",nonce="126513605503001203402405505305",uri="sip:lm.nop.qrs.tu(server)",response="014a8ffc9e6cc551acc86b22f2c26c11",algorithm=MD5 User-Agent: X-Lite release 1104o stamp 56125 Content-Length: 0 No. Time Source Destination Protocol Info 30 11.097051 ab.cde.fgh.ijk(proxy) lm.nop.qrs.tu(server) SIP Request: REGISTER sip:lm.nop.qrs.tu(server) Frame 30 (907 bytes on wire, 907 bytes captured) Ethernet II, Src: Supermic_bd:b9:bc (00:30:48:bd:b9:bc), Dst: Unispher_40:b5:39 (00:90:1a:40:b5:39) Internet Protocol, Src: ab.cde.fgh.ijk(proxy) (ab.cde.fgh.ijk(proxy)), Dst: lm.nop.qrs.tu(server) (lm.nop.qrs.tu(server)) User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060) Session Initiation Protocol Request-Line: REGISTER sip:lm.nop.qrs.tu(server) SIP/2.0 Message Header Via: SIP/2.0/UDP ab.cde.fgh.ijk(proxy);branch=z9hG4bKe0c8.73270ff2.0 Via: SIP/2.0/UDP ab.cde.fgh.ijx(xlite):50648;received=ab.cde.fgh.ijx(xlite);branch=z9hG4bK-d8754z-075267174a75f03a-1---d8754z-;rport=33374 Max-Forwards: 69 Contact: <sip:1234@ab.cde.fgh.ijx(xlite):50648;rinstance=0f34c912798e872d>;expires=0 To: "1234"<sip:1234@lm.nop.qrs.tu(server)> From: "1234"<sip:1234@lm.nop.qrs.tu(server)>;tag=cb57d146 Call-ID: Zjg5MTdhZjMyYTZlMzlmZTA2NjY4MDBhMjNhYjkyMDU. CSeq: 4 REGISTER Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Proxy-Authorization: Digest username="1234",realm="VoipSwitch",nonce="126513605503001203402405505305",uri="sip:lm.nop.qrs.tu(server)",response="014a8ffc9e6cc551acc86b22f2c26c11",algorithm=MD5 User-Agent: X-Lite release 1104o stamp 56125 Content-Length: 0 P-hint: outbound

4 5

[Kamailio-Users] protocol/port mismatch on BYE from Calle to Caller
by Arafath-uz-zaman khan 03 Feb '10

03 Feb '10

Hello All, I need a working example for sending all request to another sip server using kamailio. X-lite-->TLS(7161)-->Kamailio-->UDP(5060)-->SIP Server-->PSTN Number. i have attached my cfg file. The problem is when i dialed any pstn number everything working fine except the by msg. If the caller send BYE callee get hangup but if Calle send BYE caller never hangup the call. i got the following msg on my log file Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:parse_msg: method: <BYE> Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:parse_msg: uri: <sip:91131@192.168.10.2:5060> Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:parse_msg: version: <SIP/2.0> Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:parse_headers: flags=2 Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:get_hdr_field: cseq <CSeq>: <1> <BYE> Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:parse_via_param: found param type 232, <branch> = <z9hG4bk010213101521011481381407>; state=16 Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:parse_via: end of header reached, state=5 Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:parse_headers: via found, flags=2 Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:parse_headers: this is the first via Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:receive_msg: After parse_msg... Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:receive_msg: preparing to run routing scripts... Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:parse_headers: flags=100 Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:parse_to_param: tag=b23c1531 Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:parse_to: end of header reached, state=29 Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:parse_to: display={"91131"}, ruri={sip:91131@192.168.10.2:5060} Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:get_hdr_field: <To> [51]; uri=[sip:91131@192.168.10.2:5060] Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:get_hdr_field: to body ["91131"<sip:91131@192.168.10.2:5060>] Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:get_hdr_field: content_length=0 Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:get_hdr_field: found end of header Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:maxfwd:is_maxfwd_present: max_forwards header not found! Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:check_via_address: params 192.168.10.2, 192.168.10.2, 0 Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:parse_headers: flags=80 Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:siputils:has_totag: totag found Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:parse_headers: flags=200 Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:rr:is_preloaded: is_preloaded: No Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:grep_sock_info: checking if host==us: 12==13 && [192.168.10.2] == [192.168.10.1] Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:grep_sock_info: checking if port 5060 matches port 5060 Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:grep_sock_info: checking if host==us: 12==13 && [192.168.10.2] == [192.168.10.1] Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:grep_sock_info: checking if port 7161 matches port 5060 Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:grep_sock_info: no match for: [192.168.10.2:5060] Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:grep_aliases: no match for: [0:192.168.10.2:5060] Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:check_self: host != me Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:grep_sock_info: checking if host==us: 13==13 && [192.168.10.1] == [192.168.10.1] Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:grep_sock_info: checking if port 5060 matches port 5060 Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:grep_sock_info: match found for: [192.168.10.1:5060] Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:check_self: host == me Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:rr:after_loose: Topmost route URI: 'sip:192.168.10.1;r2=on;lr=on;nat=yes' is me Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:grep_sock_info: checking if host==us: 13==13 && [192.168.10.1] == [192.168.10.1] Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:grep_sock_info: checking if port 7161 matches port 7161 Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:grep_sock_info: match found for: [192.168.10.1:7161] Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:parse_headers: flags=200 Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:get_hdr_field: found end of header Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:rr:find_next_route: No next Route HF found Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:rr:after_loose: no next URI found Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:rr:check_route_param: params are <;r2=on;lr=on;nat=yes> Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:parse_headers: flags=40 Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:parse_to_param: tag=01021310150514813644546133 Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:parse_to: end of header reached, state=29 Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:parse_to: display={"911317434"}, ruri={sip:911317434@192.168.10.1:5060} Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:siputils:has_totag: totag found Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:tm:t_newtran: transaction on entrance=0xffffffff Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:parse_headers: flags=ffffffffffffffff Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:parse_headers: flags=78 Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:tm:t_lookup_request: start searching: hash=850, isACK=0 Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:tm:t_lookup_request: proceeding to pre-RFC3261 transaction matching Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:tm:t_lookup_request: no transaction found Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:tm:run_reqin_callbacks: trans=0xb615b5f8, callback type 1, id 0 entered Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:parse_headers: flags=78 Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:mk_proxy: doing DNS lookup... *Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:get_send_socket: force_send_socket of different proto (1)! Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: WARNING:core:get_send_socket: protocol/port mismatch* Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:tm:set_timer: relative timeout is 500000 Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:tm:insert_timer_unsafe: [4]: 0xb615b744 (46600000) Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:tm:set_timer: relative timeout is 30 Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:tm:insert_timer_unsafe: [0]: 0xb615b760 (76) Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:tm:t_relay_to: new transaction fwd'ed Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:tm:t_unref: UNREF_UNSAFE: after is 0 Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:destroy_avp_list: destroying list (nil) Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8808]: DBG:core:receive_msg: cleaning up Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8809]: DBG:tm:utimer_routine: timer routine:4,tl=0xb615b744 next=(nil), timeout=46600000 Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8809]: DBG:tm:retransmission_handler: retransmission_handler : request resending (t=0xb615b5f8, BYE sip:9 ... ) Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8809]: DBG:tm:set_timer: relative timeout is 1000000 Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8809]: DBG:tm:insert_timer_unsafe: [5]: 0xb615b744 (47600000) Feb 1 04:27:29 ser /usr/local/sbin/kamailio[8809]: DBG:tm:retransmission_handler: retransmission_handler : done Feb 1 04:27:30 ser /usr/local/sbin/kamailio[8809]: DBG:tm:utimer_routine: timer routine:5,tl=0xb615b744 next=(nil), timeout=47600000 Feb 1 04:27:30 ser /usr/local/sbin/kamailio[8809]: DBG:tm:retransmission_handler: retransmission_handler : request resending (t=0xb615b5f8, BYE sip:9 ... ) Feb 1 04:27:30 ser /usr/local/sbin/kamailio[8809]: DBG:tm:set_timer: relative timeout is 2000000 Feb 1 04:27:30 ser /usr/local/sbin/kamailio[8809]: DBG:tm:insert_timer_unsafe: [6]: 0xb615b744 (49600000) Feb 1 04:27:30 ser /usr/local/sbin/kamailio[8809]: DBG:tm:retransmission_handler: retransmission_handler : done

2 3

[Kamailio-Users] the best editor?
by BERGANZ Francois 03 Feb '10

03 Feb '10

Hello all, what is the best edit tool to see quickly the right syntax ... ? which language to choose?

5 6

[Kamailio-Users] KAMAILIO 1.4.3 no TLS Stop processing calls when Radius server goes down
by Omar 03 Feb '10

03 Feb '10

I have set it up the Radius for Kamailio, it works fine, until the Radius server goes down it did not go down for a while, when tis happes the Kamailio server stops processing any calls. I do not think is a normal behaviour, probably a bug, can anybody please tell me if this is expected behave in kamailio. or was already noticed before and was already fixed in a later release. Is possible to point to more than 2 radius servers in parallel? NOTE: i was running radius and DB in parallel with no issues, until the RADIUS server goes down. __________________________ O

3 2

[Kamailio-Users] dialog and pua_dialoginfo: Issue regarding vanished PUBLISH messages
by Martin Koenig 03 Feb '10

03 Feb '10

Hello all, I've run into an issue of Mar 2009: http://lists.kamailio.org/pipermail/users/2009-March/022143.html This seems to be unresolved in v1.5.4, the then presented work-around via modparam("pua_dialoginfo", "override_lifetime", 600) still works fine. The question is whether this should work differently nowadays, or if notice should be put into the docs? Best regards, Martin

2 2

[Kamailio-Users] alias_db: append_branches and dialog
by Martin Koenig 03 Feb '10

03 Feb '10

Hello all, two questions regarding alias_db: 1) How do I make use of the append_branches function of alias_db? Trying to insert two or more aliases is not possible in the current db layout ( UNIQUE KEY `alias_idx` (`alias_username`,`alias_domain`) ). The idea was to enable simple db-based parallel branching ("group call") via alias_db by inserting one or more users to one alias. This seems not possible. 2) Use of alias_db "breaks" presence_dialog, because dialog matching is based on from / to header (instead from / final AoR after alias_db_lookup() ), thus presence_dialog events cannot be created and PUBLISHed to end devices. I was wondering whether it would be sufficient to uac_replace_from in branch_route[] before the final t_relay work around this, or if there is another solution out there? Many thanks and best regards, Martin

2 1

Re: [Kamailio-Users] append_rpid_hf add privacy?
by Daniel-Constantin Mierla 03 Feb '10

03 Feb '10

Hello, On 2/2/10 1:18 PM, alex pappas wrote: > Hi Daniel, > > I'm capturing with tcpdump the packets when they live the server and I > don't see the extra header added. > are you having the rpid value in subscriber table? Is it loaded via load_credentials of auth_db or do you set the right avp in script? Have you tried append_hf()? Seems you want to add r-uri to rpid, which is easier via append_hf() then. Cheers, Daniel > Cheers > Alex > > > > On Tue, Feb 2, 2010 at 12:24 PM, Daniel-Constantin Mierla > <miconda(a)gmail.com <mailto:miconda@gmail.com>> wrote: > > Hi Alex, > > > On 2/2/10 11:04 AM, alex pappas wrote: > > Dear friends, > > I'm trying to give to a user the option to have privacy in a > call. I'm trying to do that by adding an extra header with: > append_rpid_hf("sip", > ";party=calling;id-type=subscriber;privacy=off;screen=no"); > > I'm using this header in the begining of the kamailio.cfg > > if(($rU=="99999") || ($rU=="77777")) > { > append_rpid_hf("sip", > "$ru;party=calling;id-type=subscriber;privacy=off;screen=no"); > xlog("alx ------- We have rU match > --------"); > } > > When I see the sip messages I don't see this extra header > added into it. > > Does anyone had experience in this ? > > the header is visible when the message is forwarded. To see it > immediately, but only in 3.0.0, you can use msg_apply_changes(). > > Cheers, > Daniel > > > -- > Daniel-Constantin Mierla > eLearning class for Kamailio 3.0.0 > Starting Feb 8, 2010 > * http://www.asipto.com/ > > -- Daniel-Constantin Mierla eLearning class for Kamailio 3.0.0 Starting Feb 8, 2010 * http://www.asipto.com/

2 4

[Kamailio-Users] preparing kamailio 1.5.4 and 1.4.5 releases
by Daniel-Constantin Mierla 02 Feb '10

02 Feb '10

Hello, soon I will start preparing the 1.5.4 and 1.4.5. The only issue reported and not clarified yet is the tcp failover that I tried to reproduce today without luck, might be dependent of (triggered faster on) particular architecture. It can be fixed once gathering more details or being able to reproduce. If you are aware of something else, please report to devel list. 1.4.5 will mark the official support for 1.4.x series, although some fixes may go back there from time to time, but I don't think will be another release of that branch. I recommend to update to newer version or stick to svn for updates. Cheers, Daniel -- Daniel-Constantin Mierla eLearning class for Kamailio 3.0.0 Starting Feb 8, 2010 * http://www.asipto.com/

1 0

[Kamailio-Users] PV bug in modules_k/acc/acc_extra.c in K 3.0.0
by Alex Balashov 02 Feb '10

02 Feb '10

I ran into a very interesting problem last night with 'acc' that took me a few hours to solve, so I am posting my workaround for collective benefit. It is probably not the cleanest and most appropriate solution because I am not extensively familiar with the 'acc' code; this is my first dive into it. Thus, I do not presume to submit an actual patch. The problem I had was that PVs read from the db_extra parameter that had an internal type of integer (TYPE_INT) because of their lexical scope were not being correctly evaluated, resulting in bizarre values being put in the database. I am using K 3.0.0 on 64-bit Xen guest running CentOS with db_postgres. I did not check to see if this problem occurs with db_mysql as I do not have MySQL anywhere nearby, but I don't believe it is happening at the database layer anyhow. I also know this problem was not present in 1.5.x, or several of my installations would be non-functional; this must have something to do with use of new 'srdb1' stuff in the database side of 'acc', I hypothesise. Anyway, the actual problem went like this. Let us say, for simplicity of example, that I am using 'acc' with Postgres backing and have something like this: modparam("acc", "db_extra", "account_id=$avp(s:account_id)") ... modparam("acc", "db_flag", 1) What was happening was that if I did this in a request route: $avp(s:account_id) = 42; ... setflag(1); if(!t_relay()) sl_reply_error(); exit; Very strange and occasionally bizarre values, mostly duplicates of other values I have in db_extra, would be written to acc.account_id (a column of type 'integer') - at any rate, certainly not 42. I enabled SQL statement logging on my PostgreSQL database to ensure that the data being inserted was literally not 42, rather than this being some sort of database-layer type conversion / representation problem. Sure enough, it was true, although I also did notice that 'acc' encloses all inserted values in single quotes to be treated as string literals. But this is immaterial, because RDBMs automatically cast such input: INSERT INTO acc (..., account_id) VALUES(..., '12'); Now, I could fix the problem by simply assigning the AVP a string literal instead: $avp(s:account_id) = '42'; Now the data was inserted normally. I also tested with user variables ($var(...)) and the same was true, so the problem is not AVP-specific. Also, all other evaluative contexts for PVs with these values work fine, such as printing them. The problem does not seem to be with 'db_postgres', neither with 'pv', nor with 'avpops' -- it is particular to 'acc'. After some hours of investigation I found that what was happening is that the type of the PV being referenced is not being correctly packed into the various arrays populated by extra2strar() in modules_k/acc/acc_extra.c, and thus was being misread when iterated in acc_db_request() in modules_k/acc/acc.c. Specifically, this check was inadequate: if (value.rs.s+value.rs.len==static_detector) { val_arr[n].s = int_buf + r*INT2STR_MAX_LEN; val_arr[n].len = value.rs.len; memcpy(val_arr[n].s, value.rs.s, value.rs.len); r++; LM_INFO("New int tenant: %s\n", val_arr[n].s); } else { val_arr[n] = value.rs; LM_INFO("New str tenant: %s\n", value.rs); } In my debugging, all PV values were showing up as "New str tenant" regardless of whether they were natively integers, and regardless of what the PV spec type was actually set to. The type was set correctly on the PV spec, so of course the integer value got stored correctly in int_var[] below: if (value.flags&PV_VAL_INT) { int_arr[n] = value.ri; type_arr[n] = TYPE_INT; } else { type_arr[n] = TYPE_STR; } ... but since 'acc' wants to treat all extra values as strings, this was not sufficient, because what was failing was this condition: if (value.rs.s+value.rs.len==static_detector) I guess value.rs.s in case of the PV value being PV_VAL_INT is not null terminated properly? This I truly do not know. In any event, I just added a check on the PV flags to see if it is an integer value and this fixed my problem: if (value.rs.s+value.rs.len==static_detector || value.flags & PV_VAL_INT) { ... however, I do not know that this was the most insightful solution. This is rather critical I think, because it means anyone trying to store PV values that are initialised with a natively numerical type in script (or extracted as a numerical value from a database, e.g. sql_query("SELECT account_id::integer FROM table ..."), I found this to be a problem as well) cannot store them in the database reliably using 'db_extra'. Thanks! -- Alex Balashov - Principal Evariste Systems LLC Tel : +1 678-954-0670 Direct : +1 678-954-0671 Web : http://www.evaristesys.com/

2 3

[Kamailio-Users] isup in invite
by Eric Hiller 02 Feb '10

02 Feb '10

I have an issue where my sip endpoint is sending ISUP information in the invite. IE: sip:+1xxxxxxxxxx;npdi=yes;cic=+1-0110@xxxx:5060 and when I run the enum query I am getting: 0(24410) enum_query(): uri user is not an E164 number This is most likely due to the fact that $rU=+17794294010;npdi=yes;cic=+1-0110 Does openser not read the user properly? Is there a way to correct this? I am running openser 1.2.2 notls Thanks for any help! -Eric _________________________________________________________________ Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. http://clk.atdmt.com/GBL/go/196390709/direct/01/

6 24

[Kamailio-Users] append_rpid_hf add privacy?
by alex pappas 02 Feb '10

02 Feb '10

Dear friends, I'm trying to give to a user the option to have privacy in a call. I'm trying to do that by adding an extra header with: append_rpid_hf("sip", ";party=calling;id-type=subscriber;privacy=off;screen=no"); I'm using this header in the begining of the kamailio.cfg if(($rU=="99999") || ($rU=="77777")) { append_rpid_hf("sip", "$ru;party=calling;id-type=subscriber;privacy=off;screen=no"); xlog("alx ------- We have rU match --------"); } When I see the sip messages I don't see this extra header added into it. Does anyone had experience in this ? Thank you Alex

2 3

[Kamailio-Users] new feature: remote user registration
by Daniel-Constantin Mierla 01 Feb '10

01 Feb '10

Hello, if you follow the sr-dev mailing list, you may have noticed some new features added in master branch (for the 3.1.0). I will send more details about each, now: remote user registration. The uac module can register in behalf of users to remote servers. The user details (credentials, local and remote username/domain) are loaded from database. The module sends registration at start-up and then refreshes just before expiration time. If the REGISTER is challenged for authentication, uac will re-send the REGISTER with proper credentials. A typical scenario is when users have accounts to many voip providers and they want to receive calls to those accounts via your sip server (inbound traffic). Of course, the user has to give details such as username/password to you. Other use case can be dynamic interconnection/peering. you can imagine a scalable solution where you have a traffic dispatcher and worker servers. When an worker becomes active, it registers to traffic dispatcher for receiving traffic... and examples can continue. Hope will help you in various cases! Readme at: http://sip-router.org/docbook/sip-router/branch/master/modules_k/uac/uac.ht… SQL to create the mysql table is in utils/kamctl/mysql/uac-create.sql Cheers, Daniel -- Daniel-Constantin Mierla * http://www.asipto.com/

4 4

[Kamailio-Users] new module: mtree
by Daniel-Constantin Mierla 01 Feb '10

01 Feb '10

Hello, the master branch got a new module named mtree. It is able to load database records in the form of (key,value) and index them in shared memory trees based on key. One db table is loaded in one mtree, you can define as many trees as you need. The typical use case is to load arbitrary data related to DIDs or prefixes, offering very fast lookup even with large number of records. The value can be string or digested in a runtime structure, so far being able to digest dstid:weight values, useful for prefix matching on weight rather than longest match. The trees are read only, with option to reload via mi command (rpc to be added soon). Online readme at: http://sip-router.org/docbook/sip-router/branch/master/modules/mtree/mtree.… Cheers, Daniel -- Daniel-Constantin Mierla eLearning class for Kamailio 3.0.0 Starting Feb 8, 2010 * http://www.asipto.com/

1 0

[Kamailio-Users] kamailio 1.4 cpc
by Asim Riaz 01 Feb '10

01 Feb '10

Hi List, Is it possible to add diffrent CPC(calling party catagory) for diffrent type of the number in the INVITE before sending out to an upstream SIP server? INVITE ----> Kamailio(add CPC) -------> SIP_Proxy_2 Thanks, Asim

3 9

[Kamailio-Users] Fosdem 2010 - reminder
by Daniel-Constantin Mierla 01 Feb '10

01 Feb '10

Hello, a reminder for those that already received (also sorry for cross-posting) and invitation for new ones, Fosdem 2010 happens this weekend in Brussels and we will have the traditional SIP routing dinner on Saturday Feb 6, trying to get all of us up-to-date regarding projects such as ser, kamailio (openser), sip-router, sems, asterisk, freeswitch, a.s.o. If you plan to attend, please confirm till Wednesday (send me an email), we need to have a fair estimation of attendees number to make the restaurant reservation. See more at: http://sip-router.org/2010/01/31/fosdem-2010-meeting-in-brussels/ See you at Fosdem, Daniel -- Daniel-Constantin Mierla eLearning Class for Kamailio 3.0.0 Starts Feb 8, 2010 * http://www.asipto.com/

1 0

[Kamailio-Users] project updates
by Daniel-Constantin Mierla 01 Feb '10

01 Feb '10

Hello, I do not know how many noticed so far, for several days the management web page was update to reflect an enlarged group of people that represent Kamailio project. Since the collaboration within SIP Router project proved fruitful, it is clear that the future development is related to that project, therefore devel decisions will happen there (join sr-dev(a)lists.sip-router.org to be in touch). The last year and half was filled with heavy integration work and testing, most of it not very challenging, but had to be done, so we wanted to acknowledge the help given by our most active community contributors. As a project policy, we maintain officially the latest two stable releases, now being 1.5.x and 3.0.x. The efforts of the group will be directed in advocating and promoting Kamailio and SIP Router projects world wide. Also some of them sponsor and take care of maintaining resources such as servers, dns and web pages. http://www.kamailio.org/mos/view/Management/ Given the big amount of work done for 3.0.0, the feedback so far is very good, in these tree weeks we discovered few issues, most relevant affecting sip_trace and uac modules, with a pretty active discussions pool about this version. 3.0.0 branches are run by some open voip providers for quite some time now (e.g., voipuser.org and iptel.org), servicing thousands of active users, ensuring that the core modules (e.g., acc, tm, auth, nat traversal, group, dialog, presence, dispatcher, pv, textops, ...) are working smooth. As a side note, I have it in other several production systems. While I encourage everyone to send feedback about 3.0.0, worth to mention that devel version (git master branch to become 3.1.0) has already quite a lot of new features, so if you are looking for adventures or need Lua API, geoip location, in memory tree indexed data, Python API, user registrations to remote SIP servers (for inbound calls), check-out git master and give it a try. Note that master is as stable as 3.0.0 branches so far regarding old code, new additions haven't touched other parts, being stand alone. Looking forward to 3.1.0 as introducing new features but also providing more tight integration with SIP Router, especially on some common used modules. Cheers, Daniel

1 0

[Kamailio-Users] help me to find the problem
by shaon＠opennets.net 31 Jan '10

31 Jan '10

Hello I am new with kamailio. here is my problem X-lite -->TLS-->Kamailio(TLS+RegisterForwrd)-->UDP-->RegisterServer-->PSTN/VOIPCall I am able to forward my register request to the register server, and make call. Able to talk from both side. But when i hangup the call from termination side call never hangup from origination side. I attached my config file. I got following log on my kamailio.log file ############# Jan 31 15:54:45 ser /usr/local/sbin/kamailio[7579]: DBG:tm:t_lookup_request: start searching: hash=53225, isACK=0 Jan 31 15:54:45 ser /usr/local/sbin/kamailio[7579]: DBG:tm:t_lookup_request: proceeding to pre-RFC3261 transaction matching Jan 31 15:54:45 ser /usr/local/sbin/kamailio[7579]: DBG:tm:t_lookup_request: no transaction found Jan 31 15:54:45 ser /usr/local/sbin/kamailio[7579]: DBG:tm:run_reqin_callbacks: trans=0xb61945d0, callback type 1, id 0 entered Jan 31 15:54:45 ser /usr/local/sbin/kamailio[7579]: DBG:core:mk_proxy: doing DNS lookup... Jan 31 15:54:45 ser /usr/local/sbin/kamailio[7579]: DBG:core:get_send_socket: force_send_socket of different proto (1)! Jan 31 15:54:45 ser /usr/local/sbin/kamailio[7579]: WARNING:core:get_send_socket: protocol/port mismatch Jan 31 15:54:45 ser /usr/local/sbin/kamailio[7579]: DBG:tm:set_timer: relative timeout is 500000 Jan 31 15:54:45 ser /usr/local/sbin/kamailio[7579]: DBG:tm:insert_timer_unsafe: [4]: 0xb619471c (40400000) Jan 31 15:54:45 ser /usr/local/sbin/kamailio[7579]: DBG:tm:set_timer: relative timeout is 30 Jan 31 15:54:45 ser /usr/local/sbin/kamailio[7579]: DBG:tm:insert_timer_unsafe: [0]: 0xb6194738 (69) Jan 31 15:54:45 ser /usr/local/sbin/kamailio[7579]: DBG:tm:t_relay_to: new transaction fwd'ed Jan 31 15:54:45 ser /usr/local/sbin/kamailio[7579]: DBG:tm:t_unref: UNREF_UNSAFE: after is 0 Jan 31 15:54:45 ser /usr/local/sbin/kamailio[7579]: DBG:core:destroy_avp_list: destroying list (nil) Jan 31 15:54:45 ser /usr/local/sbin/kamailio[7579]: DBG:core:receive_msg: cleaning up Jan 31 15:54:45 ser /usr/local/sbin/kamailio[7581]: DBG:tm:utimer_routine: timer routine:4,tl=0xb619471c next=(nil), timeout=40400000 Jan 31 15:54:45 ser /usr/local/sbin/kamailio[7581]: DBG:tm:retransmission_handler: retransmission_handler : request resending (t=0xb61945d0, BYE sip:9 ... ) Jan 31 15:54:45 ser /usr/local/sbin/kamailio[7581]: DBG:tm:set_timer: relative timeout is 1000000 Jan 31 15:54:45 ser /usr/local/sbin/kamailio[7581]: DBG:tm:insert_timer_unsafe: [5]: 0xb619471c (41400000) Jan 31 15:54:45 ser /usr/local/sbin/kamailio[7581]: DBG:tm:retransmission_handler: retransmission_handler : done Jan 31 15:54:46 ser /usr/local/sbin/kamailio[7581]: DBG:tm:utimer_routine: timer routine:5,tl=0xb619471c next=(nil), timeout=41400000 Jan 31 15:54:46 ser /usr/local/sbin/kamailio[7581]: DBG:tm:retransmission_handler: retransmission_handler : request resending (t=0xb61945d0, BYE sip:9 ... ) Can anybody help me to solve the issue? Shaon

1 0

[Kamailio-Users] ERROR:tm:w_t_reply failed to send a t_reply to a message for which no transaction-ate has been established
by AnthonyD 31 Jan '10

31 Jan '10

Dear List, I am running Kamailio (1.5.3-notls (i386/linux)) with the following modules: loadmodule "db_mysql.so" loadmodule "mi_fifo.so" loadmodule "sl.so" loadmodule "tm.so" loadmodule "rr.so" loadmodule "pv.so" loadmodule "maxfwd.so" loadmodule "usrloc.so" loadmodule "registrar.so" loadmodule "textops.so" loadmodule "uri_db.so" loadmodule "siputils.so" loadmodule "xlog.so" loadmodule "acc.so" loadmodule "avpops.so" loadmodule "lcr.so" loadmodule "dialog.so" loadmodule "auth.so" loadmodule "auth_db.so" loadmodule "domain.so" I get a lot of these errors in my logs: ERROR:tm:w_t_reply failed to send a t_reply to a message for which no transaction-ate has been established Can someone give me some info on these errors and how to trouble shoot the cause? Thanks Anthony Drozdek

2 1

[Kamailio-Users] DTLS with kamailio
by mustafa samara 31 Jan '10

31 Jan '10

Hello I want to try DTLS with kamailio, I am working on minisip it support DTLS, but what a bout the kamailio side? is there any thing to do? also i would ask about IPSec support is there any thing to do on kamailio side, or it just on the kernel level? any help please? thanks -- Eng.Mustafa Al-Samara

2 2

[Kamailio-Users] tcp_blocking_connect related errors and Kamailio using 100% CPU
by Pascal Maugeri 29 Jan '10

29 Jan '10

Hi Using Kamailio 1.5 we periodically get the following errors: Jul 1 09:54:41 localhost /usr/local/sbin/openser[3836]: ERROR:core:tcp_blocking_connect: poll error: flags 18 Jul 1 09:54:41 localhost /usr/local/sbin/openser[3836]: ERROR:core:tcp_blocking_connect: failed to retrieve SO_ERROR (110) Connection timed out Jul 1 09:54:41 localhost /usr/local/sbin/openser[3836]: ERROR:core:tcpconn_connect: tcp_blocking_connect failed Jul 1 09:54:41 localhost /usr/local/sbin/openser[3836]: ERROR:core:tcp_send: connect failed Jul 1 09:54:41 localhost /usr/local/sbin/openser[3836]: ERROR:tm:msg_send: tcp_send failed They are several emails in this mailing list explaining we should play with tcp parameters. I will try to change my configuration and see if we can solve this issue. But when this kind of error happen we observe that the kamailio processes are using 100% of CPU (top). Our client is using SIP over TCP only (no UDP). Do you have any hint on how to configure Kamailio to improve TCP support ? Is it normal to kamailio processes to overload CPU ? Regards, Pascal

5 9

Re: [SR-Users] TLS problems
by Andreas Rehbein 29 Jan '10

29 Jan '10

Hi, I solved the problem within snom370 registration with TLS: It was necessary to set the TLS-Modul Parameter "cipher_list" to RSA. Now the snom 370 registers via TLS. Thanks Klaus! regards Andreas

2 1

Re: [SR-Users] TLS problems
by Andreas Rehbein 29 Jan '10

29 Jan '10

Hello Klaus, thank you very much! I really appreciate your help! I followed your instructions and I hope that the attached file includes the necessary informations. regards Andreas -----Ursprüngliche Nachricht----- Von: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] Gesendet: Freitag, 22. Januar 2010 10:50 An: Andreas Rehbein Betreff: Re: AW: [SR-Users] TLS problems Andreas Rehbein schrieb: > Hi Klaus! > > Yes, the crash happens everytime (and immediately) when I push the > "Register"-Button in snoms web-gui. > > I attached the backtrace-file, but until now I did not rebuild kamailio with > -DDBG_QM_MALLOC. Please let me know if it's necessary. the log only shows the last function call. Please start gdb again and at the gdb prompt generate a backtrace by entering bt, e.g: (gdb) bt regards klaus > > regards > Andreas > > -----Ursprüngliche Nachricht----- > Von: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > Gesendet: Freitag, 22. Januar 2010 09:35 > An: Andreas Rehbein > Cc: sr-users(a)lists.sip-router.org > Betreff: Re: [SR-Users] TLS problems > > Hi Andreas! > > Maybe this is the same bug I reported yesterday. Unfortunately I can not > reproduce the crash anymore. > > Does the crash happen everytime? > > Kamailio produced a core dump: > > 0(6257) ALERT: <core> [main.c:725]: core was generated > > So please send a the backtrace: > # gdb kamailio /path/to/corefile > > bt > > Location of the core file is usually / or /tmp or the kamailio's working > directory. Use > # cat /proc/sys/kernel/core_pattern > to find the exact location of the core dump. > > Further, it might be useful to enable memory debugging: > - in Makefile.defs use -DDBG_QM_MALLOC instead of -DF_MALLOC and > rebuild/reinstall kamailio > - set higher loglevels in kamailio.cfg > memlog=3 > memdbg=3 > debug=3 > modparam("tls", "tls_log", 3) > > Note: this excessive logging makes kamailio start/stop real slow and > logfile will increase rapidly (might fill up your hard disk) > > regards > klaus > > > > Andreas Rehbein schrieb: >> Hi, >> >> >> >> Ive installed Kamailio 3.0 on RHEL5 and activated the mysql backend and >> tls support. Everything works fine with Soft User Agent Phoner lite. >> My Problem is: If I try to register a snom 370 Kamailio crashes >> immediatly. What is wrong? Any suggestions? >> >> Debug: >> >> 17(6290) DEBUG: <core> [ip_addr.c:116]: tcpconn_new: new tcp connection: >> 192.168.0.222 >> >> 17(6290) DEBUG: <core> [tcp_main.c:1052]: tcpconn_new: on port 1430, type > 3 >> 17(6290) DEBUG: <core> [tcp_main.c:1351]: tcpconn_add: hashes: >> 978:1690:1400, 1 >> >> 17(6290) DEBUG: <core> [io_wait.h:361]: DBG: io_watch_add(0x8222fe0, 31, >> 2, 0xb613a2b8), fd_no=24 >> >> 17(6290) DEBUG: <core> [io_wait.h:588]: DBG: io_watch_del (0x8222fe0, >> 31, -1, 0x0) fd_no=25 called >> >> 17(6290) DEBUG: <core> [tcp_main.c:3627]: tcp: DBG: sendig to child, >> events 1 >> >> 17(6290) DEBUG: <core> [tcp_main.c:3336]: send2child: to tcp child 0 >> 13(6283), 0xb613a2b8 >> >> 13(6283) DEBUG: <core> [tcp_read.c:884]: received n=4 con=0xb613a2b8, fd=8 >> >> 13(6283) DEBUG: tls [tls_server.c:109]: Using TLS domain TLSs<default> >> >> 17(6290) DEBUG: <core> [tcp_main.c:2826]: DBG: handle_tcp_child: dead >> tcp child 0 (pid 6283, no 13) (shutting down?) >> >> 17(6290) DEBUG: <core> [io_wait.h:588]: DBG: io_watch_del (0x8222fe0, >> 24, -1, 0x0) fd_no=24 called >> >> 17(6290) : <core> [pass_fd.c:283]: ERROR: receive_fd: EOF on 4 >> >> 17(6290) DEBUG: <core> [tcp_main.c:3038]: DBG: handle_ser_child: dead >> child 13, pid 6283 (shutting down?) >> >> 17(6290) DEBUG: <core> [io_wait.h:588]: DBG: io_watch_del (0x8222fe0, 4, >> -1, 0x0) fd_no=23 called >> >> 0(6257) ALERT: <core> [main.c:722]: child process 6283 exited by a >> signal 11 >> >> 0(6257) ALERT: <core> [main.c:725]: core was generated >> >> 0(6257) INFO: <core> [main.c:737]: INFO: terminating due to SIGCHLD >> >> 17(6290) INFO: <core> [main.c:788]: INFO: signal 15 received >> >> 15(6286) INFO: <core> [main.c:788]: INFO: signal 15 received >> >> 16(6289) INFO: <core> [main.c:788]: INFO: signal 15 received >> >> 12(6281) INFO: <core> [main.c:788]: INFO: signal 15 received >> >> 14(6285) INFO: <core> [main.c:788]: INFO: signal 15 received >> >> 10(6278) INFO: <core> [main.c:788]: INFO: signal 15 received >> >> 6(6269) INFO: <core> [main.c:788]: INFO: signal 15 received >> >> 2(6261) INFO: <core> [main.c:788]: INFO: signal 15 received >> >> 11(6280) INFO: <core> [main.c:788]: INFO: signal 15 received >> >> 1(6260) INFO: <core> [main.c:788]: INFO: signal 15 received >> >> 9(6276) INFO: <core> [main.c:788]: INFO: signal 15 received >> >> 8(6272) INFO: <core> [main.c:788]: INFO: signal 15 received >> >> 3(6262) INFO: <core> [main.c:788]: INFO: signal 15 received >> >> 7(6270) INFO: <core> [main.c:788]: INFO: signal 15 received >> >> 5(6267) INFO: <core> [main.c:788]: INFO: signal 15 received >> >> 4(6265) INFO: <core> [main.c:788]: INFO: signal 15 received >> >> 0(6257) DEBUG: tm [t_funcs.c:122]: DEBUG: tm_shutdown : start >> >> 0(6257) DEBUG: tm [t_funcs.c:125]: DEBUG: tm_shutdown : emptying hash > table >> 0(6257) DEBUG: tm [t_funcs.c:127]: DEBUG: tm_shutdown : removing > semaphores >> 0(6257) DEBUG: tm [t_funcs.c:129]: DEBUG: tm_shutdown : destroying tmcb >> lists >> >> 0(6257) DEBUG: tm [t_funcs.c:132]: DEBUG: tm_shutdown : done >> >> 0(6257) DEBUG: tls [tls_init.c:621]: tls module final tls destroy >> >> 0(6257) DEBUG: <core> [mem/shm_mem.c:236]: shm_mem_destroy >> >> 0(6257) DEBUG: <core> [mem/shm_mem.c:239]: destroying the shared memory >> lock >> >> 0(6257) DEBUG: <core> [main.c:741]: terminating due to SIGCHLD >> >> >> >> tia >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> sr-users mailing list >> sr-users(a)lists.sip-router.org >> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

3 9

[Kamailio-Users] kamailio 1.5.4
by Daniel-Constantin Mierla 29 Jan '10

29 Jan '10

Hello, should we package kamailio 1.5.4? 1.5.3 was in october last year, there were some commits around since then. Next week monday? 1.4.x got out of maintenance period, should we do the 1.4.5 (just release tarballs) to mark that? Cheers, Daniel -- Daniel-Constantin Mierla * http://www.asipto.com/

3 3

Re: [SR-Users] Request for a special parallel + serial forking scenario
by Klaus Feichtinger 29 Jan '10

29 Jan '10

> > Klaus Feichtinger schrieb: > > > >>> Hi, > >>> > >>> I have a special question regarding a mixture of parallel and serial > >>> forking, operated by Kamailio-3.0.0. > >>> > >>> First of all I will give you a short background information, what the > >>> target will be: > >>> > >>> I have a SIP-server on place A, 3 gateways on place B and 3 gateways > >>> on place C). These gateways are registered on SIP server (A) with > >>> different Q-values (e.g. GW-B1=1.0, GW-C1=1.0, GW-B2=0.8, GW-C2=0.8, > >>> GW-B3=0.6, GW-C3=0.6). The target is, that a call for a gateway MUST > >>> be signalled on place B and C in parallel (forking) until the call is > >>> finally established over one of the two involved gateways on place B > >>> or C. When the prime gateway(s) (with the highest Q-value) fail (e.g. > >>> they do not send a provisional response within a timeout or send a > >>> negative response), the next gateway(s) should be addressed (with the > >>> next lower Q-value), a.s.o. > >>> > >>> The configuration works well in case that both gateways on place B > >>> and C fail at the same time (BOTH do not send a response or BOTH send > >>> a negative response or one does not send a response and the other one > >>> sends a negative response). However, in case that only ONE of the two > >>> (always in parallel) addressed gateways fails, it does not work as > >>> expected. > >> > >> What is expected? > >> > >> Do you want to trigger failover to lower priority even if one the > >> gateways is still working fine? You can not do that with sip-router. > >> sr implements parallel forking according to RFC3261, this means it > >> will not generate a failure response as long as one of the branches is > >> still active, maybe sending 200 ok. > >> > > The ideal behaviour would be following: > > - try reaching a gateway on place B and C until one gateway on every > > place (B AND C) sends back a positive (provisional) response - e.g. 180 > > ringing, 183 session progress > > > > - in case that one of the two parallel addressed gateways is reachable > > and sends back a provisional response (= "it is alive"), keep it > > > > - in case that the other one (of the two parallel addressed gateways) > > has a problem (negative response 480 / 404 / 486 ...) or is unreachable > > (= |fr_inv_timer_next| timeout), try the next gateway on this specific > place > > > I'm still not sure if I understand it correct. May examples help: > > the call is forwarded to B1 and C1. B1 does not send back anything, C1 > sends back 100 trying. What is the expected behavior? > - CANCEL C1 and send the call to B2 and C2? > - keep C1 and send another call to B2? > - stay with B1 unreachable and possible C1 answering the call? > The second variant with "keep C1 and send another call to B2" is the expected behaviour. > > - the parallelism is necessary, because calls over these gateways are > > addressed to a usergroup which is split to place B and C behind a > > redundant "non-SIP" PBX system with two active halfs); you can not > > suspect if a user on place B or a user on place C will take the call; > > therefore the call has to be sent to both places. > > Ok. > > > However, the favored behaviour is not standard conform - I know. I guess > > therefore I would need a B2BUA, which is able to establish two > > independent (serially forked) preliminary connections to gateways on > > place B and C and interconnects the successful call to the call > > originator. I fear that no possibility will be available with Kamailio / > > a standard SIP server. > > Maybe you can achieve the wanted behavior by modifying tm module to > CANCEL all branches if a single branch fail (similar to processing of > 6xx error response, which also cancels all branches). > > Depending on the exact needed behavior you might be able to do it with > Asterisk. > > regards > klaus > an alternative solution I think about (but have not yet tested) might be following: - SIP server on place A fork the call to SIP servers on place B and C (both with a fix usrloc contact => parallel forking to two fix destinations) - SIP server on place B fork the call to the gateways on place B serial - SIP server on place C fork the call to the gateways on place C serial The advantage of this solution might be that not one server is responsible for making the mixture of serial AND parallel forking. Each server is responsible for making EITHER parallel (= place A) OR serial (= places B and C) forking. Could this be a practicable alternative? regards Klaus F. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

2 2

[Kamailio-Users] new feature: geoip location in cfg
by Daniel-Constantin Mierla 29 Jan '10

29 Jan '10

Hello, a new module was uploaded to master branch to lookup ip addresses against a geoip database. The module supports many lookups at the same time and returns the details in pseudo-variables. Therefore a new pv class: $gip(pvc=>key). pvc is the id of the container where to store the results of a geoip search, key is an id for the attribute you want to receive. See details on wiki: http://sip-router.org/wiki/cookbooks/pseudo-variables/devel#geoip_module_ps… Readme of the module: http://sip-router.org/docbook/sip-router/branch/master/modules/geoip/geoip.… Cheers, Daniel -- Daniel-Constantin Mierla * http://www.asipto.com/

1 0

[Kamailio-Users] documentation team
by Daniel-Constantin Mierla 29 Jan '10

29 Jan '10

Hello, following some discussions on users mailing list, seems we may get a group of people willing to digest documentation and contribute to modules' readme or wiki pages. Hopefully Alex Balashov (who volunteered so far) would have some time to coordinate contributions to git docs, for wiki being easier, as anyone has access. I am willing to help as much I can, but time is always a constraint for a dev. I invite you to join IRC channel #sip-router hosted on freenode.net to plan an synchronize easier. Thanks, Daniel -- Daniel-Constantin Mierla * http://www.asipto.com/

4 3

Re: [Kamailio-Users] /usr/local/sbin/kamdbctl create error
by Daniel-Constantin Mierla 29 Jan '10

29 Jan '10

please cc the mailing list, otherwise your emails will be ignored. do you have the mysql client installed? Can you connect to the mysql server from terminal with 'mysql' command? Cheers, Daniel On 25.11.2009 19:42 Uhr, YÜKSEL wrote: > Dear Daniel, > > Thanks for your response : Actually I am getting an error below when > I try to create DB with `/usr/local/sbin/kamdbctl create` > > debian:/usr/local/src/kamailio-1.5.0/sip-server# > /usr/local/sbin/kamdbctl create > MySQL password for root: > INFO: test server charset > /usr/local/lib/kamailio/kamctl/kamdbctl.mysql: line 105: mysql: > command not found > /usr/local/lib/kamailio/kamctl/kamdbctl.mysql: line 106: mysql: > command not found > Usage: grep [OPTION]... PATTERN [FILE]... > Try `grep --help' for more information. > /usr/local/lib/kamailio/kamctl/kamdbctl.mysql: line 112: [: =: unary > operator expected > INFO: creating database openser ... > /usr/local/lib/kamailio/kamctl/kamdbctl.mysql: line 71: mysql: command > not found > ERROR: Creating core database and grant privileges failed! > > I`ve applied the instructor one by one but I didn`t understand whay I > am getting this error. > > Regards, > > Yuksel > > > --- On *Wed, 11/25/09, Daniel-Constantin Mierla /<miconda(a)gmail.com>/* > wrote: > > > From: Daniel-Constantin Mierla <miconda(a)gmail.com> > Subject: Re: [Kamailio-Users] /usr/local/sbin/kamdbctl create error > To: "lazturk" <lazturk(a)yahoo.com> > Cc: users(a)lists.kamailio.org > Date: Wednesday, November 25, 2009, 12:33 PM > > Hello, > > > On 25.11.2009 17:59 Uhr, lazturk wrote: > > Hello, > > > > How did you solve this problem bcz I am getting a similar error ; > > > > which one? the one related to no database engine specified or the > one related to mysql socket file? > > First: updated the kamctlrc file -- see the comments inside. > > Second: check if mysql server is running and if yes, check the > mysql config to see where the server is listening and where the > mysql client tries to connect to. They must be the same. > > Cheers, > Daniel > > > > > Thanks for your feedback. > > > > > > vivi-8 wrote: > > > >> Hi all > >> I have specify the wanted db type (DBENGINE=MYSQL) in the > >> /usr/local/etc/kamailio/kamctlrc > >> then I using "/usr/local/sbin/kamdbctl create" to create MySQL > database, > >> but I got this error: > >> > >> > >> > >> ERROR: database engine not specified, please setup one in the > config > >> script > >> > >> root@acer:/usr/local/src/kamailio-1.5.0/sip-server# vim > >> /usr/local/etc/kamailio/kamctlrc > >> > >> root@acer:/usr/local/src/kamailio-1.5.0/sip-server# > >> /usr/local/sbin/kamdbctl > >> create > >> > >> MySQL password for root: > >> > >> INFO: test server charset > >> > >> ERROR 2002 (HY000): Can't connect to local MySQL server through > socket > >> '/var/run/mysqld/mysqld.sock' (2) > >> > >> ERROR 2002 (HY000): Can't connect to local MySQL server through > socket > >> '/var/run/mysqld/mysqld.sock' (2) > >> > >> Usage: grep [OPTION]... PATTERN [FILE]... > >> > >> Try `grep --help' for more information. > >> > >> /usr/local/lib/kamailio/kamctl/kamdbctl.mysql: line 112: [: =: > unary > >> operator expected > >> > >> INFO: creating database openser ... > >> > >> ERROR 2002 (HY000): Can't connect to local MySQL server through > socket > >> '/var/run/mysqld/mysqld.sock' (2) > >> > >> ERROR: Creating core database and grant privileges failed! > >> > >> > >> > >> Cheers, > >> > >> vivi > >> > >> > >> _______________________________________________ > >> Kamailio (OpenSER) - Users mailing list > >> Users(a)lists.kamailio.org </mc/compose?to=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/ > > -- Daniel-Constantin Mierla * http://www.asipto.com/

3 3

Request for a special parallel + serial forking scenario
by Klaus Feichtinger 29 Jan '10

29 Jan '10

Hi, I have a special question regarding a mixture of parallel and serial forking, operated by Kamailio-3.0.0. First of all I will give you a short background information, what the target will be: I have a SIP-server on place A, 3 gateways on place B and 3 gateways on place C). These gateways are registered on SIP server (A) with different Q-values (e.g. GW-B1=1.0, GW-C1=1.0, GW-B2=0.8, GW-C2=0.8, GW-B3=0.6, GW-C3=0.6). The target is, that a call for a gateway MUST be signalled on place B and C in parallel (forking) until the call is finally established over one of the two involved gateways on place B or C. When the prime gateway(s) (with the highest Q-value) fail (e.g. they do not send a provisional response within a timeout or send a negative response), the next gateway(s) should be addressed (with the next lower Q-value), a.s.o. The configuration works well in case that both gateways on place B and C fail at the same time (BOTH do not send a response or BOTH send a negative response or one does not send a response and the other one sends a negative response). However, in case that only ONE of the two (always in parallel) addressed gateways fails, it does not work as expected. It does nothing and/or waits for an eventually negative response or the call setup timeout. Configuration is done as described in the README of the TM module. It is a mixture of the main route and a failure_route in combination with the functions t_load_contacts() and t_next_contacts(). Does anybody have an idea how this problem could be solved or any alternative solution for this special requirement of parallel signalisation in any case? Thanks in advance! Regards, Klaus -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

2 3

[Kamailio-Users] rtpproxy session is not automatically deleted if INVITE transaction fails?
by Iñaki Baz Castillo 28 Jan '10

28 Jan '10

Hi, I'm realizing that rtpproxy session is not automatically terminated when an outgoing INVITE transaction fails ([3456]XX response received from downstream), so the rtpproxy session dies after a while due to time expiration. So I've added the following code to my on_reply_route: ------------ onreply_route[X] { if is_method("INVITE") && status =~ "[3456][0-9][0-9]" unforce_rtp_proxy(); ------------ It seems to do the job. However I expected this to be done automatically by rtpproxy module when an INVITE transaction for which a rtpproxy session has been created fails. Do I miss something? or is it the expected behavior? Thanks a lot. -- Iñaki Baz Castillo <ibc(a)aliax.net>

6 8

[Kamailio-Users] new bunch of PVs
by Daniel-Constantin Mierla 28 Jan '10

28 Jan '10

Hello, I added a bunch of new variables to deal easier with next hop address and be able to retrieve micro-seconds in the config file. Check wiki at: http://sip-router.org/wiki/cookbooks/pseudo-variables/devel#timeval http://sip-router.org/wiki/cookbooks/pseudo-variables/devel#next_hop_address Cheers, Daniel -- Daniel-Constantin Mierla * http://www.asipto.com/

1 0

[Kamailio-Users] Problems with snmpstats in Kamailio-3.0.0
by Santiago Gimeno 28 Jan '10

28 Jan '10

Hi, I'm trying to migrate from K-1.5 to K-3.0.0 and I'm having problems loading the snmpstats module in kamailio-3.0.0. The error is: ERROR: <core> [sr_module.c:390]: ERROR: load_module: could not open module </usr/local/lib/kamailio/modules_k/snmpstats.so>: /usr/local/lib/kamailio/modules_k/snmpstats.so: undefined symbol: module_loaded By checking the code it looks like module_loaded function is not implemented in sr_module.c anymore. Could this be the problem? Thanks. Best regards, Santi

3 9

Re: [Kamailio-Users] Bad URI
by Jon Farmer 28 Jan '10

28 Jan '10

On 28 January 2010 13:41, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote: > > > On 1/28/10 2:36 PM, Jon Farmer wrote: >>> >>> is the call going via route[2]? >>> >>> Try to print the whole sip message $mb before and after executing your >>> php >>> script. >>> >> >> Yes route[2] >> >> Here is a link to the $mb before and after http://pastebin.com/d4b7ca03 >> > > k, it is good, however $mb is always received message so it is the same > before and after -- just wanted to check if got corrupted. > > I want to see now the r-uri before and after: $ru > > Daniel >> Aha found it... my PHP is returning error when URI has ";user=phone". Daniel you are a star thank you for your help and patience on this one. -- Jon Farmer Tel: 07795 118140 Email: viperdudeuk(a)gmail.com Twitter: @viperdudeuk

1 0

[Kamailio-Users] Request for a special parallel serial forking scenario
by Klaus Feichtinger 28 Jan '10

28 Jan '10

Hi Kamailio users, I have a special question regarding a mixture of serial and parallel forking, operated by Kamailio-3.0.0. First of all I will give you a short background information, what the target will be: I have a SIP-server on place A, 3 gateways on place B and 3 gateways on place C). All (6) gateways are registered with the same username on SIP server (A), but with different Q-values (e.g. GW-B1=1.0, GW-C1=1.0, GW-B2=0.8, GW-C2=0.8, GW-B3=0.6, GW-C3=0.6). The target is, that a call for a gateway MUST be signalled on gateway(s) of place B and C in parallel (forking) until the call is finally established over one of the two involved gateways on place B or C. When (one of) the prime gateway(s) (with the highest Q-value) fail (e.g. they do not send a provisional response within a timeout or send a negative response), the next gateway(s) should be addressed (with the next lower Q-value), a.s.o. The parallelism for signalisation on place B and C is necessary, because of redundancy / safety reasons. Configuration for serial forking is done as described in the README of the TM module. It is a mixture of the main route and a failure_route in combination with the functions t_load_contacts() and t_next_contacts(). The loaded contacts for serial forking differ (from standard scenarios) in that way, that each sequential target consists of a pair of "users" instead of a single user. This configuration works well in case that both gateways on place B and C fail at the same time (BOTH do not send a response or BOTH send a negative response or one does not send a response and the other one sends a negative response). However, in case that only ONE of the two (always in parallel) addressed gateways fails, it does not work as expected. It does nothing and/or waits for an eventually negative response or the call setup timeout. Only then the next gateway-pair will be addressed. => is the behaviour of TM correct/"as designed" to make an AND-relation with both branches and access the failure_route only then, when both branches fail? Does anybody have an idea how this problem could be solved or any alternative solution for this special requirement of parallel signalisation in any case? Thanks in advance! Regards, Klaus -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

1 0

[Kamailio-Users] TM module
by Denis Putyato 28 Jan '10

28 Jan '10

Hello everybody! ERROR: tm [tm_load.c:47]: tm:load_tm: Module not initialized yet, make sure that all modules that need tm module are loaded after tm in the configuration file Kamailio 3.0 was installed from GIT. Kamailio starts success. But the error appears. I think because of this I have a problem with making a call through kamailio. Calls were failed because kamailio send CANCEL or 487 code immediately after send INVITE to some outgoing gateways (after t_relay() has been made). Is this really need load all modules for tm working properly? I read documentation and fount that almost all modules that need tm loaded do not need in my config. Thank you for any help.

4 11

Re: [Kamailio-Users] Bad URI
by Jon Farmer 28 Jan '10

28 Jan '10

2010/1/27 Iñaki Baz Castillo <ibc(a)aliax.net>: > El Miércoles, 27 de Enero de 2010, escribió: >> 2010/1/27 Iñaki Baz Castillo <ibc(a)aliax.net>: >> > El Miércoles, 27 de Enero de 2010, Jon Farmer escribió: >> >> Hi >> >> >> >> Does anyone know why I am getting >> >> >> >> ERROR: parse_uri: bad host in uri (error at char >> >> >> >> from this ( i hidden the domain and IP) >> > >> > How does the domain look? To show it replace the letters but keep the >> > symbols (as underscore and so). >> >> Hi, >> >> Sorry I am not entirely sure what you mean could you give me an example >> please. >> > > Hi, please keep the thread in the maillist. > > I just mean that, to keep your domain hidden, just change the letters but no > the symbols. Example: > > - Real domain: mycompany-cool-voip.com > - Showed domain: lalalaala-lolo-lili.com > > -- > Iñaki Baz Castillo <ibc(a)aliax.net> > Sorry about the wrong reply address, blame gmail :-) Here you go INVITE sip:01684299007@mydomain.net:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.20.240:5060;branch=z9hG4bK-d8754z-ed473d0ab724045f-1---d8754z-;rport. Max-Forwards: 70. Contact: <sip:500@78.32.132.193:5060>. To: <sip:01684299007@mydomain.net:5060>. From: "Michele "<sip:500@mydomain.net:5060>;tag=fd5b583a. Call-ID: NzU1MTZiMjZjZGM0ZTY5ZmFhMWRjNDlkNGQxZTZmODM.. CSeq: 2 INVITE. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO. Content-Type: application/sdp. User-Agent: 3CXPhoneSystem 7.0.4708.0. Authorization: Digest username="500",realm="mydomain.net",nonce="4b606dcc81900a95d9962d3c737cc570e624d409",uri="sip:01684299007@mydomain.net:5060",response="1ac466e73c744ed5936179152b5b27d4",algorithm=MD5. Content-Length: 278. . v=0. o=3cxPS 444025798656 5368709121 IN IP4 78.32.132.193. s=3cxPS Audio call. c=IN IP4 78.32.132.193. t=0 0. m=audio 9000 RTP/AVP 0 8 3 101. c=IN IP4 78.32.132.193. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:3 GSM/8000. a=rtpmap:101 telephone-event/8000. a=sendrecv. -- Jon Farmer Tel: 07795 118140 Email: viperdudeuk(a)gmail.com Twitter: @viperdudeuk

2 6

Re: [Kamailio-Users] ACC on Failure route
by Daniel-Constantin Mierla 28 Jan '10

28 Jan '10

On 1/25/10 2:10 PM, alex pappas wrote: > > What exactly is iirc? common abbreviation in net-slang, helping to save the planet, think green, by sending less bits on net :-): http://www.internetslang.com/IIRC.asp Cheers, Daniel -- Daniel-Constantin Mierla * http://www.asipto.com/

1 0

[Kamailio-Users] problem with ACC module
by Denis Putyato 28 Jan '10

28 Jan '10

Hello everybody! I have a such problem with ACC module. Calls was accounted but only INVITE and BYE requests has appeared in acc table. ACK is absent. Kamailio 3.0 was installed from GIT. Thank you for any help # ----- acc params ----- modparam("acc", "early_media", 0) modparam("acc", "report_ack", 1) modparam("acc", "report_cancels", 1) modparam("acc", "detect_direction", 1) modparam("acc", "db_flag", 1) modparam("acc", "db_missed_flag", 2) modparam("acc", "failed_transaction_flag", 29) modparam("acc", "db_table_acc", "acc") modparam("acc", "db_table_missed_calls", "missed_calls") modparam("acc", "acc_method_column", "method") modparam("acc", "acc_from_tag_column", "from_tag") modparam("acc", "acc_to_tag_column", "to_tag") modparam("acc", "acc_callid_column", "callid") modparam("acc", "acc_sip_code_column", "sip_code") modparam("acc", "acc_sip_reason_column", "sip_reason") modparam("acc", "acc_time_column", "time") modparam("acc", "db_url", "xxxxxxxxxxxxxxxxxxxxxxxx") modparam("acc", "db_extra", "src_user=$avp(i:2);src_domain=$si;dst_ouser=$avp(i:1);dst_user=$rU;dst_doma in=$rd") route { sip_trace(); setflag(30); if (has_totag()) { if (loose_route()) { if (is_method("BYE")) { setflag(1); setflag(29); } if (is_method("ACK")) { xlog("L_NOTICE", "ACK detected"); # I see this line in syslog setflag(1); setflag(29); } route("relay"); exit; } else { if ( is_method("ACK") ) { if ( t_check_trans() ) { setflag(1); route("relay"); exit; } else { exit; } } } }

2 1

[Kamailio-Users] Dynamic setting of dispatcher route set
by Alex Balashov 27 Jan '10

27 Jan '10

Unfortunately, ds_select_dst()/ds_select_domain() do not seem to take PVs for their first argument (the route set ID from which to choose). Is there any workaround for this, e.g. when the route set is indeterminate until runtime? It would be very inconvenient to have to work around this by implementing own rollover logic when the dispatcher module is so good... perhaps the possibility of a quick and easy patch to the git trunk? Thanks in advance! -- Alex Balashov - Principal Evariste Systems LLC Tel : +1 678-954-0670 Direct : +1 678-954-0671 Web : http://www.evaristesys.com/

2 2

[Kamailio-Users] Bad URI
by Jon Farmer 27 Jan '10

27 Jan '10

Hi Does anyone know why I am getting ERROR: parse_uri: bad host in uri (error at char from this ( i hidden the domain and IP) INVITE sip:xxxxxxxx@mydomain.net:5060;user=phone SIP/2.0. Via: SIP/2.0/UDP xx.xxx.xxx.xxx:5060;branch=z9hG4bKea312c9f5673C67A. From: "200" <sip:200@mydoamin.net>;tag=D6C112A0-D880344D. To: <sip:xxxxxxxx@mydomain.net;user=phone>. CSeq: 2 INVITE. Call-ID: f1f44bbc-58cbed36-2ea0cdab(a)xx.xxx.xxx.xxx. Contact: <sip:200@xx.xxx.xxx.xxx:5060>. Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, PRACK, UPDATE, REFER. User-Agent: PolycomSoundPointIP-SPIP_301-UA/1.6.3.0067. Supported: 100rel,replace. Allow-Events: talk,hold,conference. Authorization: Digest username="200", realm="mydomain.net", nonce="4b605fcd30e54ca4d6b52ffc9fc6128bc355cf71", uri="sip:xxxxxxxx@mydomain.net:5060;user=phone", response="7c82f9511843dc55aeaed27f468efe39", algorithm=MD5. Max-Forwards: 70. Content-Type: application/sdp. Content-Length: 254. . v=0. o=- 1264546283 1264546283 IN IP4 xx.xxx.xxx.xxx. s=Polycom IP Phone. c=IN IP4 xx.xxx.xxx.xxx. t=0 0. a=sendrecv. m=audio 10010 RTP/AVP 0 8 18 101. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:18 G729/8000. a=rtpmap:101 telephone-event/8000. -- Jon Farmer Tel: 07795 118140 Email: viperdudeuk(a)gmail.com Twitter: @viperdudeuk

2 1

Re: [Kamailio-Users] [sr-dev] Rtpproxy transcoder patch
by Henning Westerholt 27 Jan '10

27 Jan '10

On Tuesday 26 January 2010, Vikram Ragukumar wrote: > I came across a post by Stefan Sayer regarding an rtpproxy transcoder > patch http://lists.iptel.org/pipermail/serdev/2008-July/012794.html. > We are interested in having rtpproxy perform transcoding, both in > software and using DSP array cards, and are currently running rtpproxy > version 1.2.1. > Is this link http://user.cs.tu-berlin.de/~sayer/transcoder/ that is > mentioned on the post our starting point or is there an updated > version ? Hi Vikram, I don't know about this particiular case, so I can't give you more informations in this regards. But i think Stefan read this list as well, if you don't get a reply here perhaps you can contact him direcly by mail, if you have not tried this yet. Cheers, Henning

2 1

[Kamailio-Users] Wrong 1.5 wiki Cookbook page?
by Iñaki Baz Castillo 27 Jan '10

27 Jan '10

Hi, under 1.5 cookbook I see some stuf related to Kamailio 3.0. For example "debug" values are those for SR (if I'm not wrong) and the appearing command to change debug leves uses "sercmd" rather than "kamctl": http://kamailio.org/dokuwiki/doku.php/core-cookbook:1.5.x#debug Is it correct? -- Iñaki Baz Castillo <ibc(a)aliax.net>

3 4

Re: [Kamailio-Users] LCR module in Kamailio 3.0
by Daniel-Constantin Mierla 27 Jan '10

27 Jan '10

For reference: http://kamailio.org/dokuwiki/doku.php/install:1.5.x-to-3.0.0 It helps to upgrade to 3.0.0, feel free to add to the page. In this particular case, kex initializes mi engine ad registers core commands. Still don't see the dr_reload, probably the command is not registered by module's mod init. I will check. Cheers, Daniel On 1/27/10 6:43 AM, Denis Putyato wrote: > > After load kex: > > root@ubuntutest:/kamailio# kamctl fifo which > > shv_get > > shv_set > > sip_trace > > dp_reload > > dp_translate > > lcr_reload > > lcr_gw_dump > > lcr_lcr_dump > > cr_reload_routes > > cr_dump_routes > > cr_replace_host > > cr_deactivate_host > > cr_activate_host > > cr_add_host > > cr_delete_host > > uptime > > version > > pwd > > arg > > which > > kill > > ps > > debug > > get_statistics > > reset_statistics > > *From:* Daniel-Constantin Mierla [mailto:miconda@gmail.com] > *Sent:* Tuesday, January 26, 2010 9:00 PM > *To:* Denis Putyato > *Cc:* users(a)lists.kamailio.org > *Subject:* Re: [Kamailio-Users] LCR module in Kamailio 3.0 > > > > On 1/26/10 1:01 PM, Denis Putyato wrote: > > root@ubuntutest:/kamailio# kamctl fifo which > > 500 command 'which' not available > > > do you have the kex module loaded? > > Any fifo command that works for you? > > Cheers, > Daniel > > > root@ubuntutest:/kamailio# > > *From:* Daniel-Constantin Mierla [mailto:miconda@gmail.com] > *Sent:* Tuesday, January 26, 2010 2:55 PM > *To:* Denis Putyato > *Cc:* users(a)lists.kamailio.org <mailto:users@lists.kamailio.org> > *Subject:* Re: [Kamailio-Users] LCR module in Kamailio 3.0 > > > > On 1/26/10 12:35 PM, Denis Putyato wrote: > > I do not use lcr routing in config (only gw table is used). > > ok > > > > Not in kamailio 1.5 nor 3.0. I use carrierroute (in 1.5) and now > drouting (in 3.0). > > By the way. Recently you helped me with drouting. Can I ask one more > question about this module? > > When I try to do "kamctl fifo dr_reload" I receive "500 command > 'dr_reload' not available". > > > do: > > kamctl fifo which > > Should list available MI commands, is dr_reload there? > > Cheers, > Daniel > > > > *From:* Daniel-Constantin Mierla [mailto:miconda@gmail.com] > *Sent:* Tuesday, January 26, 2010 12:43 PM > *To:* Denis Putyato > *Cc:* users(a)lists.kamailio.org <mailto:users@lists.kamailio.org> > *Subject:* Re: [Kamailio-Users] LCR module in Kamailio 3.0 > > > > On 1/26/10 10:38 AM, Denis Putyato wrote: > > Daniel thank you. Now it's working > > > welcome! Be sure you understand the idea behind the instances. Not > being a user of lcr don't know exactly the internal architecture, so > as I understood from discussions on mailing lists, you can have more > lcr instance on same kamailio grouped under same value of lcr_id (many > gws and lcr rules with same lcr_id). > > Cheers, > Daniel > > > > > *From:* Daniel-Constantin Mierla [mailto:miconda@gmail.com] > *Sent:* Tuesday, January 26, 2010 12:31 PM > *To:* Denis Putyato > *Cc:* users(a)lists.kamailio.org <mailto:users@lists.kamailio.org> > *Subject:* Re: [Kamailio-Users] LCR module in Kamailio 3.0 > > Hello, > > On 1/26/10 7:33 AM, Denis Putyato wrote: > > Hello everybody! > > I have a such problem with LCR module > > When I add a new gw in gw table via kamctl addgw or direct via mysql > command, never mind, after doing lcr reload, in memory loaded only gw > with lcr_id = 1. > > All other gateways, with lcr_id > 1, not loaded into memory, so I > cannot use them. > > (After lcr reload I do lcr dump and only gateways whis lcr_id = 1 can > be seen) > > Thank you for any help. > > P.S. lcr table, where lcr_id is present too, is empty. It does not > need for processing in my kamailio. Only gw table is used. > > Kamailio 3.0 was installed from GIT. > > maybe is related to lcr_count parameter: > > http://kamailio.org/docs/modules/3.0.x/modules/lcr.html#id2495949 > > AFAIK, there were some changes in lcr by adding instances, which are > hold in lcr_id (gws to same instance have same id). > > Cheers, > Daniel > > > > > -- > Daniel-Constantin Mierla > *http://www.asipto.com/ > > > > > > -- > Daniel-Constantin Mierla > *http://www.asipto.com/ > > > _______________________________________________ > Kamailio (OpenSER) - Users mailing list > Users(a)lists.kamailio.org <mailto:Users@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/ > > > _______________________________________________ > Kamailio (OpenSER) - Users mailing list > Users(a)lists.kamailio.org <mailto:Users@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/ -- Daniel-Constantin Mierla * http://www.asipto.com/

1 0

[Kamailio-Users] LCR module in Kamailio 3.0
by Denis Putyato 27 Jan '10

27 Jan '10

Hello everybody! I have a such problem with LCR module When I add a new gw in gw table via kamctl addgw or direct via mysql command, never mind, after doing lcr reload, in memory loaded only gw with lcr_id = 1. All other gateways, with lcr_id > 1, not loaded into memory, so I cannot use them. (After lcr reload I do lcr dump and only gateways whis lcr_id = 1 can be seen) Thank you for any help. P.S. lcr table, where lcr_id is present too, is empty. It does not need for processing in my kamailio. Only gw table is used. Kamailio 3.0 was installed from GIT.

3 9

[Kamailio-Users] Rtpproxy transcoder patch
by Vikram Ragukumar 26 Jan '10

26 Jan '10

Hello, I came across a post by Stefan Sayer regarding an rtpproxy transcoder patch http://lists.iptel.org/pipermail/serdev/2008-July/012794.html. We are interested in having rtpproxy perform transcoding, both in software and using DSP array cards, and are currently running rtpproxy version 1.2.1. Is this link http://user.cs.tu-berlin.de/~sayer/transcoder/ that is mentioned on the post our starting point or is there an updated version ? Thanks and Regards, Vikram.

1 0

[Kamailio-Users] core:proxy.c problem
by marius zbihlei 26 Jan '10

26 Jan '10

Hello, There seems to be a design problem in proxy.c mk_proxy(str* name, unsigned short port, unsigned short proto, int is_sips) function. The purpose of this function is to create a proxy and return a pointer to the created structure. The issue arises from the fact that the name (type struct str) member of the proxy structure is not deep copied from the given parameters(refer to the str* name ) (the hostent structure is instead deep copied). This isn't a problem for now but I have worked on a small patch that caches proxies (using add_proxy() and find_proxy()) and ,because of this shallow copy, things are broken. I said that this is a design problem because we can let the shallow copy happen (performance is better), and when needed the caller should provide a buffer that doesn't change (let him do the copy instead). This is not clearly documented but done from /modules(_k)/utils/conf.c. But it this way we may have a memory leak when the proxy is deallocated, because I doubt that the caller keeps track of the allocated buffers(the code in proxy.c doesn't take ownership of the given pointer). This affects functions mk_proxy and mk_shm_proxy in both kamailio(1.5 to speak of) and sip-router. I have created a patch that also does a deep copy of the name, thus removing the need for the caller to bother about the lifetime of the name buffer. Any ideas?! Cheers Marius

2 3

Re: [Kamailio-Users] ACC on Failure route
by alex pappas 26 Jan '10

26 Jan '10

> Hi Daniel, > > This is my ACC configuration: > > # ----- 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) > modparam("acc", "log_extra", > > "src_user=$fU;src_domain=$fd;dst_to_user=$tU;dst_user=$rU;dst_domain=$rd;diversion_uri=$di;destination_uri=$du;display_name=$fn;orig_src_domain=$od;orig_req_uri=$ou;orig_username=$oU;prefered_identity=$pd;display_name_pref_ident=$pn;proxy_ip=$Ri;proxy_port=$Rp;src_ip=$si;dst_dom_uri=$td;user_agent=$ua") > /* uncomment the following lines to enable DB accounting also */ > modparam("acc", "db_flag", 1) > modparam("acc", "db_missed_flag", 2) > modparam("acc", "db_url", > "mysql://openser:openserrw@localhost/openser10") > modparam("acc", "db_extra", > > "src_user=$fU;src_domain=$fd;dst_to_user=$tU;dst_user=$rU;dst_domain=$rd;diversion_uri=$di;destination_uri=$du;display_name=$fn;orig_src_domain=$od;orig_req_uri=$ou;orig_username=$oU;prefered_identity=$pd;display_name_pref_ident=$pn;proxy_ip=$Ri;proxy_port=$Rp;src_ip=$si;dst_dom_uri=$td;user_agent=$ua") > > I run kamailio-1.5.3 no TLS > > What exactly is iirc? > > When i call from an user to an other and the call is passing in case of > failure from failure route1 then I get an extra cdr from the failure route1 > BUT when I call pstn and the call goes to Failure route2 then I don't get > the extra CDRs. One important diference between Failure route1 and 2 is that > in the Failure route2 I have an extra *append_branch();* > > Failure Route 1 (default) > > failure_route[1] { > xlog("alx ------- Failure Route 1 -------"); > #n# if (is_method("INVITE") > #n# && (isbflagset(6) || isflagset(5))) { > #n# unforce_rtp_proxy(); > #n# } > > 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(); > ##} > } > > Failure Route2 > > > failure_route[2] { > > if(t_was_cancelled()) { > exit; > } > > if(t_check_status("4[0-9][0-9]|5[0-9][0-9]")) > { > > #xlog("ACCOUNTING: > src_user=$fU;src_domain=$fd;dst_to_user=$tU;dst_user=$rU;dst_domain=$rd;diversion_uri=$di;destination_uri=$du;display_name=$fn;orig_src_domain=$od;orig_req_uri=$ou;orig_username=$oU;prefered_identity=$pd;display_name_pref_ident=$pn;proxy_ip=$Ri;proxy_port=$Rp;src_ip=$si;dst_dom_uri=$td;user_agent=$ua;sip_replay_reson=$rr;sip_replay_status=$T_reply_code"); > > if(ds_next_domain()) > { > xlog("alx ------------------------------------- The final RU is > $rU and the cust_prefix:$avp(s:cust_prefix) --------"); > xlog("alx ------- [ FAILURE ROUTE 2 ] First part of failure with > rd = $rd and prefix = $(ru{uri.param,prefix}) ---"); > # more destinations from same dispatcher group > > # add prefix if set and remove the param from R-URI > if($(ru{uri.param,prefix})!=null) > { > $ru = "sip:" + $avp(s:cust_prefix) + > $(ru{uri.param,prefix}) + $avp(s:user) + "@" + $rd; > } else { > $ru = "sip:" + $avp(s:cust_prefix) + $avp(s:user) + "@" + > $rd; > } > #rewriteport(5065); > #setport("5065"); > t_on_failure("2"); > *append_branch();*##################################################################### This > is different !!!!!!!!!!!!!!!!!! > t_relay(); > exit; > } else { > # go to next dispatcher group > xlog("alx ------- This is the next DST group = $avp(s:dstgrp) > -------"); > > > if($avp(s:dstgrp)!=null) > { > # select destination > if(ds_select_domain("$avp(s:dstgrp)", "4")) > { > xlog("alx ------- [ FAILURE ROUTE 2 ] Second part of > failure with rd = $rd and prefix = $(ru{uri.param,prefix}) ---"); > xlog("alx ------------------------------------- The > final RU is $rU and the cust_prefix:$avp(s:cust_prefix) --------"); > # add prefix if set and remove the param from R-URI > if($(ru{uri.param,prefix})!=null) > { > $ru = "sip:" + $avp(s:cust_prefix) + > $(ru{uri.param,prefix}) + $avp(s:user) + "@" + $rd; > } else { > $ru = "sip:" + $avp(s:cust_prefix) + $avp(s:user) > + "@" + $rd; > } > $avp(s:dstgrp) = null; > xlog("alx ------- This is the next DST group after > NULL = $avp(s:dstgrp) -------"); > xlog("alx ------- The final RURI is $ru ------- "); > t_on_failure("2"); > *append_branch();*##################################################################### > This is different !!!!!!!!!!!!!!!!!! > t_relay(); > exit; > } > } else { > t_reply("444", "No more tries for you!"); > } > } > } > > > > Thanks > Alex > > > > > On Mon, Jan 25, 2010 at 12:39 PM, Daniel-Constantin Mierla < > miconda(a)gmail.com> wrote: > >> Hi Alex, >> >> >> On 1/25/10 11:03 AM, alex pappas wrote: >> >> Hi Daniel, >> >> We make a call and the call tries from the Failure Route 5 times new >> gateway (with dispatcher) but WITHOUT success in termination. In every try >> we get back 503 Congestion. In this case how many CDRs we should see in our >> LOG. >> >> We have the modparam("acc", "failed_transaction_flag", 6) and we >> setflag(6) for every INVITE. >> >> iirc, at some point was an option to get all failed legs accounted. I >> don't remember using it so I have to check the sources (you are on 1.5.x, >> right?). >> >> For next version I plan to make acc functions available on rest of the >> routes, should be few updates to take sip method from cseq header and ignore >> r-uri if it is a reply processed, in failure route should work by default, I >> see no reasons now what could be the problem. >> >> Cheers, >> Daniel >> >> >> On Fri, Jan 22, 2010 at 3:33 PM, Daniel-Constantin Mierla < >> miconda(a)gmail.com> wrote: >> >>> Hello, >>> >>> >>> On 1/22/10 1:08 PM, alex pappas wrote: >>> >>>> Dear Friends, >>>> >>>> In case of a call failure I'm trying from failure route to send the call >>>> through other gateways with Dispatcher module. >>>> I would like to have ACC for all failures that a call can possibly pass. >>>> If the call fails in the 3 first gateways I want them also in my mysql ACC >>>> table. I tried that with AVPs in the syslog and it works fine BUT is there >>>> any way that I can simply setflag(1) for accounting and I can have ACC for >>>> every try? >>>> >>>> I tryied to add in failure route : >>>> >>>> setflag(1); # do accounting ... >>>> setflag(3); # ... even if the transaction fails >>>> >>>> but I'm getting ACC only the last try. >>>> >>>> last failed try? Or what you mean by "the last try"? IIRC, failed >>> transaction flag should be set for each leg if you want all failures. >>> >>> Cheers, >>> Daniel >>> >>> -- >>> Daniel-Constantin Mierla >>> * http://www.asipto.com/ >>> >>> >> >> _______________________________________________ >> Kamailio (OpenSER) - Users mailing list >> Users@lists.kamailio.orghttp://lists.kamailio.org/cgi-bin/mailman/listinfo/usershttp://lists.openser-project.org/cgi-bin/mailman/listinfo/users >> >> >> -- >> Daniel-Constantin Mierla >> * http://www.asipto.com/ >> >> >

3 4

[Kamailio-Users] Manipulate Berkeley DB
by Santiago Soares 26 Jan '10

26 Jan '10

Hello, I'd like to use dispatcher module with Berkeley DB. How can I manipulate the dispatcher table, I mean, insert or delete gateways? kamctl seems not to work: [root@vnsiprtest ~]# kamctl dispatcher addgw 1 '1.2.3.4' 1 'test' /usr/local/sbin/kamctl: line 1458: insert into dispatcher ( setid, destination, flags, description ) VALUES (1,'1.2.3.4',1,'test');: command not found ERROR: dispatcher - SQL Error Thank you. Santiago

2 1

[Kamailio-Users] Proxy caching patch
by marius zbihlei 26 Jan '10

26 Jan '10

Hello, I have worked lately on the patch that tries to mitigate one performance problem in core:action.c file. I am talking about the multiple calls to mk_proxy(), and the creation of temporary proxies for each FORWARD_T action that the daemon executes. I think this behaviour can be improved by caching certain proxies. My idea is this: * If the next_hop matches a name in the alias list (for example we have an alias for example.com and the next_hop is proxy1.example.com), then cache the proxy by calling add_proxy instead of mk_proxy. If the proxy is already cached a pointer is returned, if not it is created and added (the functionality already exists in proxy.c) * For all other hosts a temporary proxy is made(same as now). This whole logic can be turned off(default)/on by a parameter in .cfg. I have run some tests and this can lead to big improvemets (because mk_proxy mean some pkg_malloc - fast but also some DNS resolving - slow). This might benefit some medium-large setups where you have some servers forwarding request to other application servers, etc. The patch is very small and it's already done and finished. I will provide it tomorrow if somebody thinks this idea is good Cheers Marius

1 0

[Kamailio-Users] 30x Redirect / Forward, even questions
by Samuel Muller 26 Jan '10

26 Jan '10

Hello all, I've questions 'bout the redirect/forward with 30x requests. Actually, it does not work, it seems the uac redirect module doesn' t use the new contact for the new invite. simple schema : pstn gw -> kamailio -> linksys -> call forward unconditionnal to another pstn number -> kamailio -> gw pstn the 302 as seen with ngrep tool : #SIP/2.0 302 Moved Temporarily. #To: <sip:B@sip_proxy;user=phone>;tag=91515579fff6b8d1i0. #From: <sip:A@pstn_gw1;user=phone>;tag=16627-UI-00020cf3-54eea92c4. #Call-ID: 16627-RO-00020cf2-4186e9762@pstn_gw1. #CSeq: 81990 INVITE. #Via: SIP/2.0/UDP sip_proxy;branch=z9hG4bK0f0c.22989b87.1. #Via: SIP/2.0/UDP pstn_gw1:5060;rport=5060;received=ip_pstn_gw1;branch=z9hG4bK-25EA-243F3. #Record-Route: <sip:sip_proxy;lr=on;ftag=16627-UI-00020cf3-54eea92c4;did=f65.bcc44f06>. #Contact: <sip:C@sip_proxy>. #Diversion: "B" <sip:B@sip_proxy>;reason=unconditional. #Server: Linksys/SPA942-6.1.3(a). DBG:uac_redirect:shmcontact2dset: adding contact <sip:C@sip_proxy> dest set : Contact: sip:B@ip_B, <sip:C@sip_proxy>;q=0.01 contact $ct: <sip:pstn_gw1:5060> the second pstn gateway received a request to B, and not C (so it creates a loop through pstn ...). in my config : loadmodule "uac.so" modparam("uac", "rr_store_param", "vsf") modparam("uac", "from_restore_mode", "auto") loadmodule "uac_redirect.so" modparam("uac_redirect", "default_filter", "accept") modparam("uac_redirect","bflags", 1) loadmodule "diversion.so" failure_route[2] { setdebug(4); if (t_check_status("301|302")) { route(26) # acc fwd $avp(s:acc_status) = "cfu"; if (!get_redirects("2:1")) { xlog("L_NOTICE", "failed to extract contact info from 30x header"); route(10); # stop rtp t_reply("480", "Temporarily Unavailable"); exit; } # flag 3xx status, open a new branch and back to find the new callee setflag(28); append_branch(); t_on_branch("1"); route(3); # search the new callee setdebug(); exit; } t_on_branch("1"); setdebug(); route(3); # find callee route(12); # local outbound route(10); # stop rtp } I'm using lcr module to route calls, kamailio v. 1.5.3. I've another question, is the 30x always considered as a failure_route ? Any help and/or explanations about the tricks would be really appreciated ... thanks, -- Samuel MULLER sml(a)l33.fr

2 4

[Serusers] Questions about the command : serctl fifo
by inge 26 Jan '10

26 Jan '10

Hi, I am using SER 0.9.9. I have questions about two commands "serctl fifo" : - serctl fifo t_stats : What does mean the "current", "waiting" and "total" values returned by the command? - serctl fifo ul_stats : What does mean the two values returned on the line "location"? Regards, David.

1 0

[Kamailio-Users] Global constants
by Alex Balashov 26 Jan '10

26 Jan '10

Daniel, What is the recommended way (if any) to have a "global constant" that exists outside of any particular routes, in K3? My objective is to define a global DB_URL that can be used by all modules everywhere, but I can't just 'and' the modules together, e.g. modparam("mod1|mod2|mod3|...", "db_url", "...") because the modules are dynamically included (thanks to include_file!) and I do not know the list of all loaded modules easily at runtime. So instead, db_url is configured on a per-module basis. I thought preprocessor constants (e.g. #!define and friends) would allow me to set values for them, but they don't, so that's out. What other options are available that do not involve an event/local route, and operate instead in the completely global namespace? Right now, I am using a Perl script that manually substitutes the value of the db_url modparam everywhere in a large directory tree. :/ What am I not thinking of? Cheers, -- Alex -- Alex Balashov - Principal Evariste Systems LLC Tel : +1 678-954-0670 Direct : +1 678-954-0671 Web : http://www.evaristesys.com/

2 1

[Kamailio-Users] Active dialogs waaaay to high
by Anders 26 Jan '10

26 Jan '10

Hi, When I run 'kamctl fifo get_statistics all calls', it tells me that the the number of dialogs is about 2000 times higher than what it really is. Actually it seems like it has added a couple of thousand to the number. How do I 'reset' this number? A restart of kamailio didn't help... Thanks! //Anders

2 1

[Kamailio-Users] "Permanent" AVP
by Antonio Reale 26 Jan '10

26 Jan '10

Hi all, I'd like to simulate in kamailio 1.4.4, the loading of a global setting (like a parameter that is loaded only at startup), using AVPs. So, I want to load some AVP only at proxy startup. Probably it is not possible because, if I'm not wrong, AVPs are transaction persistent. The problem is that I don't need to load those AVPs for every transaction. There is a why to implement such configuration? Thanks. Best regards. -- Antonio

3 5

[Kamailio-Users] 477 Send failed
by vragukumar＠signalogic.com 25 Jan '10

25 Jan '10

Hello, I have setup Kamailio and rtpproxy on a server, that acts as a SIP Proxy. An asterisk server sits behind this proxy server. I have noticed that on some occasions when the softphone(x-lite) tries to register with the asterisk through the proxy,it receives a 477 send failed. If i restart Kamailio, the problem seems to disappear. I have attached a logfile showing Kamailio's error output. What could be the reason for such behavior ? Thanks and Regards, Vikram.

3 2

[Serusers] how to compile the docs?
by Chump Chumpster 25 Jan '10

25 Jan '10

Hi, I'm sure this is a simple question and hopefully a simple answer. I've downloaded and am experimenting with SER 2.0.x. I can't find any instructions on how to compile the docs included with the source, into a usable format. They're pretty difficult to use as XML without a stylesheet :-) I appreciate any advice to get me going in the right direction....

1 0

[Kamailio-Users] Fwd: TLS Multiple records not read
by Jijo Jose 25 Jan '10

25 Jan '10

Thanks for the response. The SIP server is reading only the first record(first sip message), the _tls_read() function's log shows the length of first sip message which is matching with length of first record in wireshark.. This means SSL_read returns only the first record. I did the test using TCP which is working fine as it is reading two sip messages on a single read. Please find the log and attached print screen of wireshark traces. Jan 22 20:41:37 REGS-1a0240 openser[936]: io_wait_loop_sigio_rt: siginfo: signal=35 (35), si_code=1, si_band=0x41, si_fd=37 Jan 22 20:41:37 REGS-1a0240 openser[936]: TCPCONN: handle_io: fd map 0x1011d73c (37): {37, 2, 0x30294da0} Jan 22 20:41:37 REGS-1a0240 openser[936]: tls_update_fd: New fd is 37 Jan 22 20:41:37 REGS-1a0240 openser[936]: _tls_read: 559 bytes read Jan 22 20:41:37 REGS-1a0240 openser[936]: read= 559 bytes, parsed=559, state=4, error=1 Jan 22 20:41:37 REGS-1a0240 openser[936]: tcp_read_req: last char=0x0A, parsed msg= BYE sip:551138175007@21.21.81.11:6061;transport=tls SIP/2.0^M To: SIP5007_TLS_SIMPLEX <sip:551138175007@41.41.0.230<sip%3A551138175007(a)41.41.0.230>>;tag=91c2c894c0^M From: <sip:551138175008@41.41.0.230:5061;transport=tls>;tag=snl_G84KdX4MLT^M Call-ID: 0ad3e453326a4160^M CSeq: 1 BYE^M Route: <sip:21.21.27.10:5061;transport=tls;ftag=91c2c894c0;lr=on>^M Via: SIP/2.0/TLS 41.41.0.230:5061;branch=z9hG4bK_brancha_41.41.0.230_KonTU5DMPx^M Accept-Language: en;q=0.0^M Allow: REGISTER, INVITE, ACK, BYE, CANCEL, NOTIFY, REFER^M Date: Fri, 22 Jan 2010 20:41:36 GMT ^M Max-Forwards: 69^M Content-Length: 0^M ^M Jan 22 20:41:37 REGS-1a0240 openser[936]: tcp_read_req: end of header part Jan 22 20:41:37 REGS-1a0240 openser[936]: - received from: port 5061 Jan 22 20:41:37 REGS-1a0240 openser[936]: - received from: ip 41.41.0.230 Jan 22 20:41:37 REGS-1a0240 openser[936]: tcp_read_req: headers: BYE sip:551138175007@21.21.81.11:6061;transport=tls SIP/2.0^M To: SIP5007_TLS_SIMPLEX <sip:551138175007@41.41.0.230<sip%3A551138175007(a)41.41.0.230>>;tag=91c2c894c0^M From: <sip:551138175008@41.41.0.230:5061;transport=tls>;tag=snl_G84KdX4MLT^M Call-ID: 0ad3e453326a4160^M CSeq: 1 BYE^M Route: <sip:21.21.27.10:5061;transport=tls;ftag=91c2c894c0;lr=on>^M Via: SIP/2.0/TLS 41.41.0.230:5061;branch=z9hG4bK_brancha_41.41.0.230_KonTU5DMPx^M Accept-Language: en;q=0.0^M Allow: REGISTER, INVITE, ACK, BYE, CANCEL, NOTIFY, REFER^M Date: Fri, 22 Jan 2010 20:41:36 GMT ^M Max-Forwards: 69^M Content-Length: 0^M ^M . Jan 22 20:41:37 REGS-1a0240 openser[936]: tcp_read_req: content-length= 0 Jan 22 20:41:37 REGS-1a0240 openser[936]: tcp_read_req: body: Jan 22 20:41:37 REGS-1a0240 openser[936]: calling receive_msg(0x30294e14, 559, ) Jan 22 20:41:37 REGS-1a0240 openser[936]: SIP Request: Jan 22 20:41:37 REGS-1a0240 openser[936]: method: <BYE> Jan 22 20:41:37 REGS-1a0240 openser[936]: uri: <sip:551138175007@21.21.81.11:6061;transport=tls> Jan 22 20:41:37 REGS-1a0240 openser[936]: version: <SIP/2.0> Thanks Jijo On Sun, Jan 24, 2010 at 5:53 AM, Klaus Darilion < klaus.mailinglists(a)pernau.at> wrote: > I would verify if the received fragment really contains 2 complete SIP > messages (e.g. 2xCRLF at the end of the SIP headers and if Content-Length > header is correct). > > For debugging, TLS is PITA. > > Maybe the SIP server shows the same behavior when using TCP. Otherwise you > can try to configure the NULL:CIPHER on both servers - then you see the > plaintext SIP message in the TLS packets. > > regards > klaus > > Jijo Jose wrote: > >> Hi All, >> We have a SIP server which enabled NAGLE algorithm and proxy as openser >> ver 1.1 >> SIP Server send a TLS multiple records( 2 SIP messages) in a packet to >> openser. Openser is reading only the first record( first SIP message). The >> second TLS record(sip message) is read only when the next message recieved >> by openser from the SIP Server. >> I would like to know anybody observed this issue. I have compared the >> codebase of kamailio 1.4 and openser 1.1 but didin't find any diffrence for >> TLS. >> I have looked at the API _tls_read() in openser which is same as that of >> kamilio. >> Don't we need to use SSL_pending() after SSL_read() to verify any buffer >> is left in the SSL layer ? >> Do you think is it due to the poll method error? The poll method we use >> is POLL_SIGIO_RT >> Please let me know your comments. >> Thanks in advance. >> Jijo >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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 >> > >

2 4

[Kamailio-Users] load drouting
by Denis Putyato 25 Jan '10

25 Jan '10

Hello everybody! Such error happens when I try start kamailio Jan 25 10:52:57 ubuntutest kamailio: ERROR: <core> [sr_module.c:390]: ERROR: load_module: could not open module </usr/local/lib/kamailio/modules_k/drouting.so>: /usr/local/lib/kamailio/modules_k/drouting.so: undefined symbol: db_bind_mod Jan 25 10:52:57 ubuntutest kamailio: : <core> [cfg.y:3326]: parse error in config file /usr/local/etc/kamailio/kamailio.cfg, line 42, column 12-24: failed to load module ls /usr/local/lib/kamailio/modules_k/ acc.so db_text.so group.so nathelper.so pv.so sl.so uac_redirect.so alias_db.so dialog.so htable.so nat_traversal.so qos.so sms.so uac.so auth_db.so dispatcher.so imc.so path.so ratelimit.so speeddial.so uri_db.so auth_diameter.so diversion.so kex.so pdt.so registrar.so sqlops.so userblacklist.so auth.so domainpolicy.so maxfwd.so permissions.so rr.so sst.so usrloc.so benchmark.so domain.so mi_datagram.so pike.so rtimer.so statistics.so xlog.so call_control.so drouting.so mi_fifo.so presence_mwi.so siptrace.so textops.so cfgutils.so exec.so msilo.so pua_mi.so siputils.so tmx.so In config file: loadpath "/usr/local/lib/kamailio/modules:/usr/local/lib/kamailio/modules_k" loadmodule "db_mysql.so" loadmodule "mi_fifo.so" loadmodule "sl.so" loadmodule "tm.so" loadmodule "rr.so" loadmodule "pv.so" loadmodule "textops.so" loadmodule "siputils.so" loadmodule "xlog.so" loadmodule "acc.so" loadmodule "avpops.so" loadmodule "siptrace.so" loadmodule "dialplan.so" loadmodule "lcr.so" loadmodule "sqlops.so" loadmodule "carrierroute.so" loadmodule "drouting.so" Kamailio ver 3.0 was installed from GIT. Thank you for any help

2 4

[Kamailio-Users] Outgoing registrations
by Andrey Utkin 25 Jan '10

25 Jan '10

How do you make outgoing registrations to sip providers' accounts? I haven't found Kamailio functionality like this, so looks this requires some b2bua usage? Is there some other way?

3 6

[Kamailio-Users] Option ac_extra_hdrs to tm in K 3.0.x
by Alex Balashov 25 Jan '10

25 Jan '10

What exactly is the appropriate syntax for the value of the ac_extra_hdrs option in K3's 'tm'? As described here, it is not very clear: http://www.kamailio.org/docs/modules/3.0.x/modules/tm.html#ac_extra_hdrs modparam("tm", "ac_extra_hdrs", "myfavoriteheaders-") What does this mean? Where do I put the header name, and what is the delimeter? Is it a semicolon or colon-separated list? What if, for example, I want to pass X-Alex-Status and X-Alex-Cause in CANCELs and negative ACKs from the original INVITE? Do I use ... modparam("tm", "ac_extra_hdrs", "X-Alex_Status;X-Alex-Cause") If so, what is the significance of the '-' in the above example? Thanks! -- Alex Balashov - Principal Evariste Systems LLC Tel : +1 678-954-0670 Direct : +1 678-954-0671 Web : http://www.evaristesys.com/

2 3

[Kamailio-Users] ACC on Failure route
by alex pappas 25 Jan '10

25 Jan '10

Dear Friends, In case of a call failure I'm trying from failure route to send the call through other gateways with Dispatcher module. I would like to have ACC for all failures that a call can possibly pass. If the call fails in the 3 first gateways I want them also in my mysql ACC table. I tried that with AVPs in the syslog and it works fine BUT is there any way that I can simply setflag(1) for accounting and I can have ACC for every try? I tryied to add in failure route : setflag(1); # do accounting ... setflag(3); # ... even if the transaction fails but I'm getting ACC only the last try. Thanks Alex

3 11

[Kamailio-Users] TLS Multiple records not read
by Jijo Jose 24 Jan '10

24 Jan '10

Hi All, We have a SIP server which enabled NAGLE algorithm and proxy as openser ver 1.1 SIP Server send a TLS multiple records( 2 SIP messages) in a packet to openser. Openser is reading only the first record( first SIP message). The second TLS record(sip message) is read only when the next message recieved by openser from the SIP Server. I would like to know anybody observed this issue. I have compared the codebase of kamailio 1.4 and openser 1.1 but didin't find any diffrence for TLS. I have looked at the API _tls_read() in openser which is same as that of kamilio. Don't we need to use SSL_pending() after SSL_read() to verify any buffer is left in the SSL layer ? Do you think is it due to the poll method error? The poll method we use is POLL_SIGIO_RT Please let me know your comments. Thanks in advance. Jijo

2 1

[Kamailio-Users] state field on dialog table
by Panagiotis Skoulikaritis 23 Jan '10

23 Jan '10

Hello I have a question about the state field on the dialog table. I guess it is more sip protocol oriented than kamailio deployment, I assume that the values (1-5) that are logged are the state of the dialog correct ? and if the above are correct the dialog states are the following ? 1. waiting for UAC deciscion 2. Initiate dialog 3. Establish dialog 4. Stop Media 5. Destroy dialog I apologize for my sip ignorance Trying to build up my knowledge. :) I' m asking this because I' m trying to export statistics about the calls that are handled from the kamailio and the state of the call for specific users,IP's, destinations. Thanks Panagiotis

4 5

[Kamailio-Users] mysql loadbalancing
by BERGANZ François 22 Jan '10

22 Jan '10

Hello, I need to know if Kamailio can change Mysql Server if there is a problem with a mysql server ? Can Kamailio do loadbalancing between 2 mysql servers which are duplicate ? Thank you François BERGANZ

5 17

TLS problems
by Andreas Rehbein 22 Jan '10

22 Jan '10

Hi, I've installed Kamailio 3.0 on RHEL5 and activated the mysql backend and tls support. Everything works fine with Soft User Agent "Phoner lite". My Problem is: If I try to register a "snom 370" Kamailio crashes immediatly. What is wrong? Any suggestions? Debug: 17(6290) DEBUG: <core> [ip_addr.c:116]: tcpconn_new: new tcp connection: 192.168.0.222 17(6290) DEBUG: <core> [tcp_main.c:1052]: tcpconn_new: on port 1430, type 3 17(6290) DEBUG: <core> [tcp_main.c:1351]: tcpconn_add: hashes: 978:1690:1400, 1 17(6290) DEBUG: <core> [io_wait.h:361]: DBG: io_watch_add(0x8222fe0, 31, 2, 0xb613a2b8), fd_no=24 17(6290) DEBUG: <core> [io_wait.h:588]: DBG: io_watch_del (0x8222fe0, 31, -1, 0x0) fd_no=25 called 17(6290) DEBUG: <core> [tcp_main.c:3627]: tcp: DBG: sendig to child, events 1 17(6290) DEBUG: <core> [tcp_main.c:3336]: send2child: to tcp child 0 13(6283), 0xb613a2b8 13(6283) DEBUG: <core> [tcp_read.c:884]: received n=4 con=0xb613a2b8, fd=8 13(6283) DEBUG: tls [tls_server.c:109]: Using TLS domain TLSs<default> 17(6290) DEBUG: <core> [tcp_main.c:2826]: DBG: handle_tcp_child: dead tcp child 0 (pid 6283, no 13) (shutting down?) 17(6290) DEBUG: <core> [io_wait.h:588]: DBG: io_watch_del (0x8222fe0, 24, -1, 0x0) fd_no=24 called 17(6290) : <core> [pass_fd.c:283]: ERROR: receive_fd: EOF on 4 17(6290) DEBUG: <core> [tcp_main.c:3038]: DBG: handle_ser_child: dead child 13, pid 6283 (shutting down?) 17(6290) DEBUG: <core> [io_wait.h:588]: DBG: io_watch_del (0x8222fe0, 4, -1, 0x0) fd_no=23 called 0(6257) ALERT: <core> [main.c:722]: child process 6283 exited by a signal 11 0(6257) ALERT: <core> [main.c:725]: core was generated 0(6257) INFO: <core> [main.c:737]: INFO: terminating due to SIGCHLD 17(6290) INFO: <core> [main.c:788]: INFO: signal 15 received 15(6286) INFO: <core> [main.c:788]: INFO: signal 15 received 16(6289) INFO: <core> [main.c:788]: INFO: signal 15 received 12(6281) INFO: <core> [main.c:788]: INFO: signal 15 received 14(6285) INFO: <core> [main.c:788]: INFO: signal 15 received 10(6278) INFO: <core> [main.c:788]: INFO: signal 15 received 6(6269) INFO: <core> [main.c:788]: INFO: signal 15 received 2(6261) INFO: <core> [main.c:788]: INFO: signal 15 received 11(6280) INFO: <core> [main.c:788]: INFO: signal 15 received 1(6260) INFO: <core> [main.c:788]: INFO: signal 15 received 9(6276) INFO: <core> [main.c:788]: INFO: signal 15 received 8(6272) INFO: <core> [main.c:788]: INFO: signal 15 received 3(6262) INFO: <core> [main.c:788]: INFO: signal 15 received 7(6270) INFO: <core> [main.c:788]: INFO: signal 15 received 5(6267) INFO: <core> [main.c:788]: INFO: signal 15 received 4(6265) INFO: <core> [main.c:788]: INFO: signal 15 received 0(6257) DEBUG: tm [t_funcs.c:122]: DEBUG: tm_shutdown : start 0(6257) DEBUG: tm [t_funcs.c:125]: DEBUG: tm_shutdown : emptying hash table 0(6257) DEBUG: tm [t_funcs.c:127]: DEBUG: tm_shutdown : removing semaphores 0(6257) DEBUG: tm [t_funcs.c:129]: DEBUG: tm_shutdown : destroying tmcb lists 0(6257) DEBUG: tm [t_funcs.c:132]: DEBUG: tm_shutdown : done 0(6257) DEBUG: tls [tls_init.c:621]: tls module final tls destroy 0(6257) DEBUG: <core> [mem/shm_mem.c:236]: shm_mem_destroy 0(6257) DEBUG: <core> [mem/shm_mem.c:239]: destroying the shared memory lock 0(6257) DEBUG: <core> [main.c:741]: terminating due to SIGCHLD tia

2 4

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