sr-users December 2012

sr-users@lists.kamailio.org

71 participants
113 discussions

Preparing for the next major release
by Olle E. Johansson 06 Dec '12

06 Dec '12

Hi! Daniel has set a code freeze date for the next major release and the Kamailio community needs to work together to prepare the release. That means you as well! There will be a lot of work in the coming weeks to merge code from SIP router into the Kamailio core to complete the merger process. We also have a large set of new modules and functions to test. The creation of a new release is much more than code - it's testing, documentation proof-reading and feedback. With a large and complex piece of software like Kamailio we can't test all functions with all possible combinations of configurations and connections to third party products - this is where YOU can help out! Read more on http://www.kamailio.org/w/2012/12/preparations-for-new-release/ and join us in creating the new release! /O

1 0

Kamailio Load Balancing, problems ACK and BYE.
by Nguyen Anh Tuan 06 Dec '12

06 Dec '12

Hi everyone, I am a beginner in using Kamailio. I am currently building a load balancer for multiple SIP Servers, all of them are Kamailio. The Load balancer can help end-users REGISTER and INVITE normally, but has problems with ACK and BYE. Messages 180 Ringing and 200 OK sent successfully to the Caller, but the ACK failed, is transmitted to the SIP Server then stop here, doesn't go back to Load balancing. (Caller's BYE -> LB -> Proxy then stop here). Because doesn't receive ACK, the Called continuously sent 200 call OK to Caller (sent successfully) and wait for confirmation ACK (after arrival to the SIP Server, ACK doesn't come back to Load Balancing). Because the Called party doesn't receive ACK, the call will be automatically disconnected after 30 seconds. With BYE have rather, if the Caller hangs up first, BYE is transferred over SIP Server and returned to Load balancer, but Load Balancing can't sent it to the Called (Caller's BYE -> LB -> Proxy -> LB then do not go to the side of called). Caller had picked off the phone, but the Caller is not received BYE and after 30 seconds the call will automatically disconnect (by ACK errors). If the called party hangs up first, HUNG UP button of the called even useless, and I don't see any packet of the Called party's BYE message in Wireshark. I use X-Lite and EyeBeam for two end users, the configuration of the SIP Server is the default configuration of Kamailio. DISPATHCHER.LIST: I have 3 Kamailio SIP Proxies, all of them OK, share one DB located in Proxy 2. But for capturing packets more convenient, I turn off the Proxy 2 and 3. # group sip addresses of your * units # Kamailio SIP Proxies/Registrars 1 sip:192.168.3.11:5060 #1 sip:192.168.3.12:5060 #1 sip:192.168.3.13:5060 Previously I used the Stateless Load Balancing configuration by default, but could not INVITE: # -- dispatcher params -- modparam("dispatcher", "list_file", "/etc/kamailio/dispatcher.list") modparam("dispatcher", "force_dst", 1) route{ if ( !mf_process_maxfwd_header("10") ) { sl_send_reply("483","To Many Hops"); drop(); }; ds_select_dst("1", "0"); record_route(); forward(); # t_relay(); } Then I changed the following, sent INVITE and setup call successfully, but met ACK and BYE error above. if ( is_method("INVITE")) { # Not Dispatch INVITE from SIP Proxies if ( ds_is_from_list("1") ) { t_relay(); } else if ( !ds_is_from_list("1") ) { route(DISPATCH); } } else { # If not INVITE route(DISPATCH); } } route[DISPATCH] { # dispatch destinations ds_select_dst("1", "0"); record_route(); t_relay(); #forward(); } Please tell me How to modify in the configuration of Proxy and Load Balancing? Thank so much for helping! Best Regard Nguyen Anh Tuan, -------------------------------------------------------------------- The latest 200 OK from Called after Ringing : LB->Caller Via: SIP/2.0/UDP 172.24.104.159:9040;received=192.168.3.88;branch=z9hG4bK-d87543-a7349502ae55 cf46-1--d87543-;rport=9040 Record-Route: <sip:192.168.3.11;lr;nat=yes> Record-Route: <sip:192.168.3.10;lr=on> Contact: <sip:1004@192.168.3.10:5060;rinstance=040c24111dc72132> To: "1004"<sip:1004@registrar.sip.vn>;tag=8e782d60 From: "1001 registrar.sip.vn"<sip:1001@registrar.sip.vn>;tag=7c72f24e Call-ID: 1926bb7b58289f2fODg1OTZlZGE5MTAxN2JhOWJjNTZmOGQ1OTljOTJiNjc. CSeq: 2 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Content-Type: application/sdp User-Agent: eyeBeam release 1102q stamp 51814 Content-Length: 435 Caller's ACK (1001(a)192.168.3.88) to Load Balancer (192.168.3.10): Via: SIP/2.0/UDP 172.24.104.159:9040;branch=z9hG4bK-d87543-6f1c8659392a0773-1--d87543-;rport Max-Forwards: 70 Route: <sip:192.168.3.10;lr> Route: <sip:192.168.3.11;lr;nat=yes> Contact: <sip:1001@192.168.3.88:9040> To: "1004"<sip:1004@registrar.sip.vn>;tag=8e782d60 From: "1001 registrar.sip.vn"<sip:1001@registrar.sip.vn>;tag=7c72f24e Call-ID: 1926bb7b58289f2fODg1OTZlZGE5MTAxN2JhOWJjNTZmOGQ1OTljOTJiNjc. CSeq: 2 ACK Proxy-Authorization: Digest username="1001",realm="registrar.sip.vn",nonce="T4uyKE+LsPwWJBt3JseE7OVdd58P 32lS",uri="sip:1004@registrar.sip.vn",response="ec2a4c8832bc7bf7665811c26ec9 b292",algorithm=MD5 User-Agent: eyeBeam release 1003s stamp 31159 Content-Length: 0 ACK 192.168.3.10:5060 (Load Balance) to 192.168.3.11:5060 (Proxy) then STOP HERE (Not transfer further) Via: SIP/2.0/UDP 192.168.3.10;branch=z9hG4bKcydzigwkX Via: SIP/2.0/UDP 192.168.3.10;branch=z9hG4bKcydzigwkX Via: SIP/2.0/UDP 172.24.104.159:9040;received=192.168.3.88;branch=z9hG4bK-d87543-6f1c8659392a 0773-1--d87543-;rport=9040 Max-Forwards: 68 Contact: <sip:1001@192.168.3.88:9040> To: "1004"<sip:1004@registrar.sip.vn>;tag=8e782d60 From: "1001 registrar.sip.vn"<sip:1001@registrar.sip.vn>;tag=7c72f24e Call-ID: 1926bb7b58289f2fODg1OTZlZGE5MTAxN2JhOWJjNTZmOGQ1OTljOTJiNjc. CSeq: 2 ACK Proxy-Authorization: Digest username="1001",realm="registrar.sip.vn",nonce="T4uyKE+LsPwWJBt3JseE7OVdd58P 32lS",uri="sip:1004@registrar.sip.vn",response="ec2a4c8832bc7bf7665811c26ec9 b292",algorithm=MD5 User-Agent: eyeBeam release 1003s stamp 31159 Content-Length: 0 Caller's BYE (1001(a)192.168.3.88) to Load Balance (192.168.3.10) Via: SIP/2.0/UDP 172.24.104.159:9040;branch=z9hG4bK-d87543-616e232f86191a37-1--d87543-;rport Max-Forwards: 70 Route: <sip:192.168.3.10;lr> Route: <sip:192.168.3.11;lr;nat=yes> Contact: <sip:1001@192.168.3.88:9040> To: "1004"<sip:1004@registrar.sip.vn>;tag=8e782d60 From: "1001 registrar.sip.vn"<sip:1001@registrar.sip.vn>;tag=7c72f24e Call-ID: 1926bb7b58289f2fODg1OTZlZGE5MTAxN2JhOWJjNTZmOGQ1OTljOTJiNjc. CSeq: 3 BYE Proxy-Authorization: Digest username="1001",realm="registrar.sip.vn",nonce="T4uyKE+LsPwWJBt3JseE7OVdd58P 32lS",uri="sip:1004@192.168.3.10:5060;rinstance=040c24111dc72132",response=" c738898739dc49c02676e04a28761971",algorithm=MD5 User-Agent: eyeBeam release 1003s stamp 31159 Reason: SIP;description="User Hung Up" Content-Length: 0 BYE was transferred from Load Balance(192.168.3.10) to Proxy (192.168.3.11), repeated THREE TIMES, possibly due to an error loop (Route(DISPATCH)?) Record-Route: <sip:192.168.3.10;lr=on> Via: SIP/2.0/UDP 192.168.3.10;branch=z9hG4bKc5be.03f49894.1 Via: SIP/2.0/UDP 172.24.104.159:9040;received=192.168.3.88;branch=z9hG4bK-d87543-616e232f8619 1a37-1--d87543-;rport=9040 Max-Forwards: 69 Route: <sip:192.168.3.10;lr> Contact: <sip:1001@192.168.3.88:9040> To: "1004"<sip:1004@registrar.sip.vn>;tag=8e782d60 From: "1001 registrar.sip.vn"<sip:1001@registrar.sip.vn>;tag=7c72f24e Call-ID: 1926bb7b58289f2fODg1OTZlZGE5MTAxN2JhOWJjNTZmOGQ1OTljOTJiNjc. CSeq: 3 BYE Proxy-Authorization: Digest username="1001",realm="registrar.sip.vn",nonce="T4uyKE+LsPwWJBt3JseE7OVdd58P 32lS",uri="sip:1004@192.168.3.10:5060;rinstance=040c24111dc72132",response=" c738898739dc49c02676e04a28761971",algorithm=MD5 User-Agent: eyeBeam release 1003s stamp 31159 Reason: SIP;description="User Hung Up" Content-Length: 0 Via: SIP/2.0/UDP 192.168.3.10;branch=z9hG4bKc5be.13f49894.0 Via: SIP/2.0/UDP 192.168.3.10;branch=z9hG4bKc5be.03f49894.0 Via: SIP/2.0/UDP 172.24.104.159:9040;received=192.168.3.88;branch=z9hG4bK-d87543-616e232f8619 1a37-1--d87543-;rport=9040 Max-Forwards: 68 Contact: <sip:1001@192.168.3.88:9040> To: "1004"<sip:1004@registrar.sip.vn>;tag=8e782d60 From: "1001 registrar.sip.vn"<sip:1001@registrar.sip.vn>;tag=7c72f24e Call-ID: 1926bb7b58289f2fODg1OTZlZGE5MTAxN2JhOWJjNTZmOGQ1OTljOTJiNjc. CSeq: 3 BYE Proxy-Authorization: Digest username="1001",realm="registrar.sip.vn",nonce="T4uyKE+LsPwWJBt3JseE7OVdd58P 32lS",uri="sip:1004@192.168.3.10:5060;rinstance=040c24111dc72132",response=" c738898739dc49c02676e04a28761971",algorithm=MD5 User-Agent: eyeBeam release 1003s stamp 31159 Reason: SIP;description="User Hung Up" Content-Length: 0 Record-Route: <sip:192.168.3.10;lr=on> Via: SIP/2.0/UDP 192.168.3.10;branch=z9hG4bKc5be.13f49894.1 Via: SIP/2.0/UDP 192.168.3.10;branch=z9hG4bKc5be.03f49894.0 Via: SIP/2.0/UDP 172.24.104.159:9040;received=192.168.3.88;branch=z9hG4bK-d87543-616e232f8619 1a37-1--d87543-;rport=9040 Max-Forwards: 68 Contact: <sip:1001@192.168.3.88:9040> To: "1004"<sip:1004@registrar.sip.vn>;tag=8e782d60 From: "1001 registrar.sip.vn"<sip:1001@registrar.sip.vn>;tag=7c72f24e Call-ID: 1926bb7b58289f2fODg1OTZlZGE5MTAxN2JhOWJjNTZmOGQ1OTljOTJiNjc. CSeq: 3 BYE Proxy-Authorization: Digest username="1001",realm="registrar.sip.vn",nonce="T4uyKE+LsPwWJBt3JseE7OVdd58P 32lS",uri="sip:1004@192.168.3.10:5060;rinstance=040c24111dc72132",response=" c738898739dc49c02676e04a28761971",algorithm=MD5 User-Agent: eyeBeam release 1003s stamp 31159 Reason: SIP;description="User Hung Up" Content-Length: 0 Send back BYE from SIP Proxy (192.168.3.11) to Load Balance (192.168.3.10) Record-Route: <sip:192.168.3.10;lr=on> Via: SIP/2.0/UDP 192.168.3.11;branch=z9hG4bKc5be.0070e643.0 Via: SIP/2.0/UDP 192.168.3.10;rport=5060;branch=z9hG4bKc5be.03f49894.1 Via: SIP/2.0/UDP 172.24.104.159:9040;received=192.168.3.88;branch=z9hG4bK-d87543-616e232f8619 1a37-1--d87543-;rport=9040 Max-Forwards: 68 Contact: <sip:1001@192.168.3.10:5060> To: "1004"<sip:1004@registrar.sip.vn>;tag=8e782d60 From: "1001 registrar.sip.vn"<sip:1001@registrar.sip.vn>;tag=7c72f24e Call-ID: 1926bb7b58289f2fODg1OTZlZGE5MTAxN2JhOWJjNTZmOGQ1OTljOTJiNjc. CSeq: 3 BYE Proxy-Authorization: Digest username="1001",realm="registrar.sip.vn",nonce="T4uyKE+LsPwWJBt3JseE7OVdd58P 32lS",uri="sip:1004@192.168.3.10:5060;rinstance=040c24111dc72132",response=" c738898739dc49c02676e04a28761971",algorithm=MD5 User-Agent: eyeBeam release 1003s stamp 31159 Reason: SIP;description="User Hung Up" Content-Length: 0 BYE LOOPs Back from Load Balance(192.168.3.10) to Proxy (192.168.3.11), possibly due to an error loop (Route(DISPATCH)?) Record-Route: <sip:192.168.3.10;lr=on> Record-Route: <sip:192.168.3.10;lr=on> Via: SIP/2.0/UDP 192.168.3.10;branch=z9hG4bKc5be.33f49894.0 Via: SIP/2.0/UDP 192.168.3.10;branch=z9hG4bKc5be.23f49894.0 Via: SIP/2.0/UDP 192.168.3.11;branch=z9hG4bKc5be.0070e643.0 Via: SIP/2.0/UDP 192.168.3.10;rport=5060;branch=z9hG4bKc5be.03f49894.1 Via: SIP/2.0/UDP 172.24.104.159:9040;received=192.168.3.88;branch=z9hG4bK-d87543-616e232f8619 1a37-1--d87543-;rport=9040 Max-Forwards: 66 Contact: <sip:1001@192.168.3.10:5060> To: "1004"<sip:1004@registrar.sip.vn>;tag=8e782d60 From: "1001 registrar.sip.vn"<sip:1001@registrar.sip.vn>;tag=7c72f24e Call-ID: 1926bb7b58289f2fODg1OTZlZGE5MTAxN2JhOWJjNTZmOGQ1OTljOTJiNjc. CSeq: 3 BYE Proxy-Authorization: Digest username="1001",realm="registrar.sip.vn",nonce="T4uyKE+LsPwWJBt3JseE7OVdd58P 32lS",uri="sip:1004@192.168.3.10:5060;rinstance=040c24111dc72132",response=" c738898739dc49c02676e04a28761971",algorithm=MD5 User-Agent: eyeBeam release 1003s stamp 31159 Reason: SIP;description="User Hung Up" Content-Length: 0

1 0

Kamailio Load Balancing, problems ACK and BYE.
by Nguyen Anh Tuan 06 Dec '12

06 Dec '12

1 0

Segmentation fault in sip-capture
by Owen Lynch 05 Dec '12

05 Dec '12

Hi, I am running Kamailio 3.3 as a Homer capture agent, the sip-capture module receives HEP packets from a sip-trace module in a remote kamailio instance. Periodically the capture agent dies. The log and core dump suggest the initial problem is an invalid HEP msg received, but kamailio crashes when trying to send an error reply. Can anyone shed any light on this? Thanks, Owen Lynch Back trace: Program terminated with signal 11, Segmentation fault. #0 0x0813c916 in send2child (tcpconn=0xb55c1c60) at tcp_main.c:3967 3967 tcp_main.c: No such file or directory. in tcp_main.c Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.80.el6.i686 keyutils-libs-1.4-4.el6.i686 krb5-libs-1.9-33.el6.i686 libcom_err-1.41.12-12.el6.i686 libselinux-2.0.94-5.3.el6.i686 mysql-libs-5.1.61-4.el6.i686 nss-softokn-freebl-3.12.9-11.el6.i686 openssl-1.0.0-20.el6_2.5.i686 zlib-1.2.3-27.el6.i686 (gdb) bt #0 0x0813c916 in send2child (tcpconn=0xb55c1c60) at tcp_main.c:3967 #1 0x08136e78 in handle_tcpconn_ev (fm=<value optimized out>, ev=<value optimized out>, idx=<value optimized out>) at tcp_main.c:4310 #2 handle_io (fm=<value optimized out>, ev=<value optimized out>, idx=<value optimized out>) at tcp_main.c:4362 #3 0x0813ea3c in io_wait_loop_epoll () at io_wait.h:1092 #4 tcp_main_loop () at tcp_main.c:4656 #5 0x080a502b in main_loop () at main.c:1727 #6 0x080a6c00 in main (argc=11, argv=0xbfeafd14) at main.c:2546 Log: Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19568]: : <core> [pass_fd.c:288]: ERROR: receive_fd: recvmsg on 10 failed: Connection reset by peer Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19568]: ERROR: <core> [tcp_main.c:2347]: BUG: tcp_send: failed to get fd(receive_fd): Connection reset by peer (104) Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19568]: ERROR: sl [../../forward.h:193]: msg_send: ERROR: tcp_send failed Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19568]: ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio.cfg] l=704 a=3 n=exit Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19568]: DEBUG: <core> [usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list (nil) Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19568]: DEBUG: <core> [usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list (nil) Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19568]: DEBUG: <core> [usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list (nil) Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19568]: DEBUG: <core> [usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list (nil) Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19568]: DEBUG: <core> [usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list (nil) Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19568]: DEBUG: <core> [usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list (nil) Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19568]: DEBUG: <core> [xavp.c:365]: destroying xavp list (nil) Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19568]: DEBUG: <core> [receive.c:293]: receive_msg: cleaning up Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19568]: ERROR: sipcapture [sipcapture.c:682]: ERROR: sipcapture:hep_msg_received: not supported version or bad length: v:[10] l:[10] vs [40] Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19568]: DEBUG: <core> [parser/msg_parser.c:634]: SIP Reply (status): Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19568]: DEBUG: <core> [parser/msg_parser.c:636]: version: <SIP/2.0> Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19568]: DEBUG: <core> [parser/msg_parser.c:638]: status: <500> Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19568]: DEBUG: <core> [parser/msg_parser.c:640]: reason: <Invalid CSeq> Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19568]: DEBUG: <core> [parser/parse_via.c:1286]: Found param type 234, <received> = <yadayadayada>; state=6 Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19568]: DEBUG: <core> [parser/parse_via.c:1286]: Found param type 232, <branch> = <z9hG4bK2348.d1620f62.0>; state=16 Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19568]: DEBUG: <core> [parser/parse_via.c:2561]: end of header reached, state=5 Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19568]: DEBUG: <core> [parser/msg_parser.c:511]: parse_headers: Via found, flags=2 Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19568]: DEBUG: <core> [parser/msg_parser.c:513]: parse_headers: this is the first via Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19567]: ALERT: <core> [main.c:785]: child process 19576 exited by a signal 11 Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19567]: ALERT: <core> [main.c:788]: core was generated Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19567]: INFO: <core> [main.c:800]: INFO: terminating due to SIGCHLD Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19575]: INFO: <core> [main.c:851]: INFO: signal 15 received Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19574]: INFO: <core> [main.c:851]: INFO: signal 15 received Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19573]: INFO: <core> [main.c:851]: INFO: signal 15 received Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19572]: INFO: <core> [main.c:851]: INFO: signal 15 received Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19567]: DEBUG: tm [t_funcs.c:122]: DEBUG: tm_shutdown : start Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19567]: DEBUG: tm [t_funcs.c:125]: DEBUG: tm_shutdown : emptying hash table Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19567]: DEBUG: tm [t_funcs.c:127]: DEBUG: tm_shutdown : removing semaphores Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19567]: DEBUG: tm [t_funcs.c:129]: DEBUG: tm_shutdown : destroying tmcb lists Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19567]: DEBUG: tm [t_funcs.c:132]: DEBUG: tm_shutdown : done Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19567]: DEBUG: tls [tls_init.c:674]: tls module final tls destroy Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19567]: DEBUG: <core> [mem/shm_mem.c:242]: shm_mem_destroy Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19567]: DEBUG: <core> [mem/shm_mem.c:245]: destroying the shared memory lock Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19567]: DEBUG: <core> [main.c:804]: terminating due to SIGCHLD

2 5

modules_s/eval - survey of usage
by Daniel-Constantin Mierla 05 Dec '12

05 Dec '12

Hello, is anyone using the modules_s/eval module? In the context of merging modules_s/* to modules/*, this one lacks the docbook xml files for readme. It has a text readme file, from where I understand it does script operations using a stack and polish notation expressions. Probably it was developed before the expressions support in config file language, at this moment all its operations can be done directly by the interpreter. I am considering moving the module to obsolete/ folder. If anyone is using it and wants to keep it in modules/*, then he/she has to convert the readme text into docbook format (which is not complex at all, just takes a bit of time, probably like 60 min or even less). If there is no answer in one week about usage, will be sent to obsolete/, from where it can be rescued in case of need (just to be clear for everybody that code is not lost). Cheers, Daniel -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

1 0

dns resolver issue (RFC3263)
by MÉSZÁROS Mihály 05 Dec '12

05 Dec '12

Hi All, I am experiencing an issue when i try to contact xy(a)cisco.com. I found that kamailio/sip-router can't resolve by default resolving way a TCP + SRV records from domain cisco.com. e.g. cisco.com misi@alma:~$ host -t NAPTR cisco.com cisco.com has no NAPTR record misi@alma:~$ host -t SRV _sip._udp.cisco.com Host _sip._udp.cisco.com not found: 3(NXDOMAIN) misi@alma:~$ host -t SRV _sip._tcp.cisco.com _sip._tcp.cisco.com has SRV record 1 0 5060 vcsgw.cisco.com. misi@alma:~$ host -t SRV _sips._tcp.cisco.com _sips._tcp.cisco.com has SRV record 1 0 5061 vcsgw.cisco.com. I can't call xy(a)cisco.com because it does not exists an NAPTR record in domain cisco.com, and furthermore no SRV with udp. But it exists sip+tcp record and also exists an secure sip SRV, so sips+tcp record! I read rfc3263 I find kamailio dns resolver is not working as it should according RFC3263. http://tools.ietf.org/html/rfc3263 _If no NAPTR records are found, the client constructs SRV queries for those transport protocols it supports, and does a query for each._ So kamailio should query all (udp, tcp, tls, sctp whatever) protocols. Can anyone help/guide me to create a fix to this issue? My plan is to create a patch to kamailio resolver, to correct and behave according RFC3263. Any help or guidance appreciated! Thanks, Misi

4 14

syslog message about invalid domain name
by Juha Heinanen 05 Dec '12

05 Dec '12

when i t_relay in-dialog bye: Request-Line: BYE sip:0x8eb94d0@[2002:c062:660a::1]:5050;transport=tcp SIP/2.0 Message Header Via: SIP/2.0/TCP [2002:C062:660A:0:0:0:0:1];branch=z9hG4bKde53.6aaed77ea908953bbb133e5021d74036.0 Via: SIP/2.0/UDP [::1]:5090;received=0:0:0:0:0:0:0:1;branch=z9hG4bKq~ouJaGs;rport=5090 From: <sip:jh@as.test.fi>;tag=5A29C828-50BEFE55000C7118-B4FF9B70 To: "" <sip:test@test.fi>;tag=92e26ffbfbc16e53 CSeq: 10 BYE Call-ID: 28d1e4872cc5f83e User-Agent: Sip Express Media Server (1.6.0 (x86/linux)) Max-Forwards: 69 Content-Length: 0 with $du set to sip:[2002:C062:660A:0:0:0:0:1]:59933;transport=tcp, i get to syslog: Dec 5 09:53:48 sip /usr/sbin/sip-proxy[1947]: INFO: <core> [resolve.c:729]: invalid domain name '[2002:C062:660A:0:0:0:0:1]' since everything is and works as expected, why is the info message produced and how can i get rid of it? -- juha

2 2

Xcap server chooice among openSER, mobicents and openXCAP
by zhi sun 05 Dec '12

05 Dec '12

hi guys, it is my first time to use XCAP, i want to implement XCAP server to support maybe huge amount of user accesses (as cloud solution), so far, i can find out three XCAP server solution: 1. openSER with XCAP Server Module http://kamailio.org/docs/modules/devel/modules_k/xcap_server.html 2. mobicents with XCAP component/server build-in http://code.google.com/p/mobicents/wiki/Welcome?tm=6 http://www.mobicents.org/diameter/index.html http://hudson.jboss.org/hudson/view/Mobicents/job/Mobicents-Books/lastSucce… 3. openXCAP http://www.ag-projects.com/projects-products-96/101-openxcap but i am not clear to choose with solution to best match my situation (high volumn, high scale, and quick response). - does openSER support the cloud solution with high volum, high scale? - is it easy to use/integrate the XCAP server independently from mobicents? - is there performance issue for openXCAP, because it is implemented using python? any suggestions would be appreciated! best regards, -iamsy

1 0

io_wait errors
by Juha Heinanen 05 Dec '12

05 Dec '12

any idea what could be the cause for lots of these kind syslog messages: Dec 3 23:11:36 sip2 /usr/sbin/sip-proxy[5490]: : <core> [pass_fd.c:293]: ERROR: receive_fd: EOF on 56 Dec 3 23:11:36 sip2 /usr/sbin/sip-proxy[5490]: ERROR: <core> [io_wait.h:628]: ERROR: io_watch_del: trying to delete already erased entry 56 in the hash(-1, 0, 0xb2f28adc) flags 0) Dec 3 23:11:36 sip2 /usr/sbin/sip-proxy[5490]: ERROR: <core> [io_wait.h:628]: ERROR: io_watch_del: trying to delete already erased entry 59 in the hash(-1, 0, 0xb725a9d8) flags 0) Dec 3 23:11:36 sip2 /usr/sbin/sip-proxy[5490]: : <core> [pass_fd.c:209]: ERROR: send_fd: sendmsg failed sending 58 on 59: Broken pipe (32) Dec 3 23:11:36 sip2 /usr/sbin/sip-proxy[5490]: ERROR: <core> [tcp_main.c:4003]: ERROR: send2child: send_fd failed for 0xb3024a48 (flags 0x4018), fd 58 -- juha

2 2

[Kamailio-Users] BYE message not relayed to caller
by Vikram Ragukumar 04 Dec '12

04 Dec '12

Hello, My setup includes a cellphone that uses Wi-Fi to hookup to the internet with IP 192.168.1.101. Cellphone app, tries to register with VOIPSwitch through an outbound proxy server(Kamailio + rtpproxy), which rewrites SDP to force rtp through an rtpproxy. I can make a call from the cellphone to a PSTN number. When the PSTN endpoint hangs up, VOIPSwitch relays a BYE message to the proxy that looks like : No. Time Source Destination Protocol Info 27 18.383929 IPaddr_VoipSwitch IPaddr_proxy SIP Request: BYE sip:1234@IPaddr_VoipSwitch Frame 27 (420 bytes on wire, 420 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: IPaddr_VoipSwitch , Dst: IPaddr_proxy User Datagram Protocol, Src Port: sip (5060), Dst Port: 7160 (7160) Session Initiation Protocol Request-Line: BYE sip:1234@IPaddr_VoipSwitch SIP/2.0 Method: BYE [Resent Packet: False] Message Header Route: <sip:IPaddr_proxy:7160;lr=on;nat=yes> CSeq: 1 BYE Via: SIP/2.0/UDP IPaddr_VoipSwitch:5060; branch=z9hG4bk180242100434182912333954 From: sip:5678@IPaddr_VoipSwitch;tag=18024210041929123187506289 Call-ID: LUOyIDm-ecy36NcUfj5G3v1lM6g5snkM To: "1234" <sip:1234@IPaddr_VoipSwitch>;tag=9XHJmiuf58vTrF7.vwflEK-G63JVPQSi Content-Length: 0 The request URI in the above message is the IP address of VOIPSwitch itself, which causes the proxy to forward the BYE message back to VOIPSwitch. The cellphone never receives the BYE message and consequently never hangs up. Any suggestions on how i can get around this problem ? Thanks and Regards, Vikram.

3 9

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 December 2012