- sr-users - kamailio.org

The SIP protocol v2 - we're giving up.
by Olle E. Johansson 01 Apr '11

01 Apr '11

Friends, After having spent many years working with the Asterisk SIP channel driver, Kamailio and the SIPv2 protocol, I have finally realized that this is a dead end. It's getting nowhere and it's way too complicated to set up, run and support in working code. After realizing this, I started a new standardization project together with my friends in Canada, Simon and Marc, to develop a working solution based on the combination of IPv6 and SIP. We have gotten great feedback and now the IETF, the ITU and the IPv6 forum jointly launches the new standard, SIP-six. From the press release: "”We realize that 99% of the SIP users use SIP for PSTN phone calls. The original SIP standards was written with other applications in mind, a vision that never came true.” said Bob Plug, area director in the IETF. ”That’s why we sat down and said to ourselves that this should be way more simple.” The SIP-six standard totally removes the dependency of domains and URI syntax. There’s no point in using this, since everyone seems to think that IP addressing is more than enough. The new standard use part of the vast IPv6 address space to incorporate the E.164 phone numbers as addresses. This is the reverse of the reverse phone number usage in the enum standard, which is no longer needed in SIP-six. By using IPv6 mobile IP, phone users register their phones and get access to their phone number. Users that need security can easily integrate IPsec into their setup. Media and signalling uses the same addressing scheme and is mixed so that both SIP-six, RTP and RTCP only uses one port address - but in this case a port address with 32 bit subaddress identifying the media stream. This finally solves a lot of the firewall traversal issues that SIP v2.0 had. With the combination of mobile IP and use of public IPv6 addresses NAT traversal won’t be an issue. The testbed for SIP-six has been running for a year at six choosen large SIP carriers, with the assistance of Edvina AB in Sweden and ViaGenius in Montreal, Canada. In an International effort, the testbed is today put in production and Roboid phones all over the world is automatically connected to this worldwide network." You will be able to find out more about it here: http://bit.ly/sipsix SIP-six is implemented as a channel driver in Asterisk 2.0, as a replacement for SIP2.0 in Kamailio 4.0 and a channel module in FreeSwitch - all releases to be released later today. Softphones for testing will shortly be available from Blink and Zoiper. Looking forward to continue this project with the rest of the Kamailio/SIP-router community! Special thanks to Daniel for the reference implementation in Kamailio 4.0! Have a nice weekend! /Olle

7 7

valgrind errors from 3.1-stable (git 2fe4d633e4ac)
by Timo Teräs 01 Apr '11

01 Apr '11

Hi all, I'm running 3.1-branch git head currently under valgrind. And I've seen several invalid reads and writes (apparently most are off by one). ==22274== Invalid read of size 1 ==22274== at 0x6DA2C0A: pv_set_ruri_user (pv_core.c:1755) ==22274== by 0x13BA15: lval_pvar_assign (lvalue.c:357) ==22274== by 0x13BF0F: lval_assign (lvalue.c:405) ==22274== by 0x139E4D: do_action (action.c:1472) ==22274== by 0x13A6F1: run_actions (action.c:1555) ==22274== by 0x12FDEB: do_action (action.c:711) ==22274== by 0x13A6F1: run_actions (action.c:1555) ==22274== by 0x13A86F: run_actions_safe (action.c:1607) ==22274== by 0x1E2666: rval_get_int (rvalue.c:904) ==22274== by 0x1E5252: rval_expr_eval_int (rvalue.c:1866) ==22274== by 0x131B8A: do_action (action.c:1071) ==22274== by 0x13A6F1: run_actions (action.c:1555) Is fairly obvious. modules_k/pv/pv_core.c has several places which take backup of "val->rs.s[val->rs.len]" and replaces it with zero for string termination. It's than later on set back to the original value. However, it would appear that the value passed does not always point to a memory area which is large enough. This results in multiple invalid reads and writes of one. The remaining reads are not so clear to me. ==22274== Invalid read of size 1 ==22274== at 0x4811A69: strncpy (mc_replace_strmem.c:339) ==22274== by 0x6DA77FF: set_var_value (pv_svar.c:122) ==22274== by 0x6DA1EDB: pv_set_scriptvar (pv_core.c:1636) ==22274== by 0x13BA15: lval_pvar_assign (lvalue.c:357) ==22274== by 0x13BF0F: lval_assign (lvalue.c:405) ==22274== by 0x139E4D: do_action (action.c:1472) ==22274== by 0x13A6F1: run_actions (action.c:1555) ==22274== by 0x131E05: do_action (action.c:1086) ==22274== by 0x13A6F1: run_actions (action.c:1555) ==22274== by 0x12FDEB: do_action (action.c:711) ==22274== by 0x13A6F1: run_actions (action.c:1555) ==22274== by 0x131E05: do_action (action.c:1086) ==22274== Invalid read of size 2 ==22274== at 0x4811E1F: memcpy (mc_replace_strmem.c:523) ==22274== by 0x1E134D: rval_new_str (rvalue.c:269) ==22274== by 0x1E394E: rval_convert (rvalue.c:1301) ==22274== by 0x1E4780: rval_str_add2 (rvalue.c:1610) ==22274== by 0x1E8681: rval_expr_eval (rvalue.c:2399) ==22274== by 0x13BBD9: lval_assign (lvalue.c:389) ==22274== by 0x139E4D: do_action (action.c:1472) ==22274== by 0x13A6F1: run_actions (action.c:1555) ==22274== by 0x12FDEB: do_action (action.c:711) ==22274== by 0x13A6F1: run_actions (action.c:1555) ==22274== by 0x139229: do_action (action.c:1342) ==22274== by 0x13A6F1: run_actions (action.c:1555) Any ideas how to fix these? Or any instructions what to provide more in the bug report? Cheers, Timo

3 7

RPM packages for Kamailio 3.1.2
by Daniel-Constantin Mierla 31 Mar '11

31 Mar '11

Hello, there is now a service on opensuse build server to create kamailio v3.1.2 (git branch 3.1.2) RPMs i586/x86_63 for Centos 5.5, RedHat 5, Fedora 14 and OpenSuse 11.4, you can check this project at: https://build.opensuse.org/package/show?package=kamailio&project=home%3Akam… Download links are: http://download.opensuse.org/repositories/home:/kamailio:/telephony/CentOS_… http://download.opensuse.org/repositories/home:/kamailio:/telephony/RedHat_… http://download.opensuse.org/repositories/home:/kamailio:/telephony/Fedora_… http://download.opensuse.org/repositories/home:/kamailio:/telephony/openSUS… The x86_64 build for opensuse is still not completed, some parameter to gcc compiler is not working, should be fixed soon. Note that not all modules are packaged since not all dependencies were met in these distros. The RPM spec was started from what is in source tree as kamailio.spec.CentOS, radically updated for cross compilation. Personally I am not using these distros, therefore it will be appreciated if people using any of them are willing to give an installation test and report if all goes ok. Moreover, I will be very thankful if anyone (can be many) wants to jump in and take over the maintenance of this kamailio build service. It would be good to enable the build for other versions of these distros, probably for many it will just work, if not it will require some adjustments on dependencies. Once these builds prove to be ok and useful, we can move them in the global telephony repository of the opensuse build service. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

2 1

LCR defunct_gw use
by Ricardo Martinez 31 Mar '11

31 Mar '11

Hello. Can someone please explain to me hoy can i use the command “defunct_gw()” is used to mark a gw down?. I understand that the gateway is marked down for period of time with the command, but how can I check if a gateway is down?. Can someone show me this with an example in the configuration? *Thanks in advance,* *Regards,* * * * * *Ricardo Martinez.-*

5 9

accounting problem
by Parikhita Behera 31 Mar '11

31 Mar '11

Hi , Currently i am working with opensips and i am able to call throgh opensips and show the cdrs but there is problem of accounting that how i can give the balance to the customer and how to charge the rates for diffrent country. There is the option call control for opensips and this is related to media proxy and radius server. I am using centos OS for opensips .Please help me if any body know this options(call control). Waiting for your response. Thanks and Regards Parikhita

2 1

Re: [SR-Users] Outbound socket selection (HA implementation)
by Sean O'Donnell 31 Mar '11

31 Mar '11

For what it's worth, make sure you have the mhomed patch in forward.c. As I recall, the 3.1.2 source tarball did not contain the fix, but the latest forward.c did. http://www.mail-archive.com/sr-users@lists.sip-router.org/msg03892.html Sean O'Donnell Senior Engineer uReach Technologies, Inc. ---- On Wed, 30 Mar 2011, Bruce McAlister (bruce.mcalister(a)blueface.ie) wrote: All, Thanks for the tips and suggestions, I have now managed to get this working using mhomed=1 and setting $fs, for some reason I could not get "force_send_socket" to work with avp's (but thats a topic for another thread). Thanks again for your time. _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

2 1

Outbound socket selection (HA implementation)
by Asgaroth 31 Mar '11

31 Mar '11

Hi All, I'm trying to setup an active/passive proxy instance with kamailio 3.1.2. I'm using ucarp (www.ucarp.org) to provide the floating ip addresses. I have installed and configured ucarp and it appears to be working as expected. I have configured kamailio on both systems to be online all the time (using the net.ipv4.ip_nonlocal_bind kernel parameter on the "standby" server). I have configured kamailio with the listen parameter to be listening on the floating ip addresses only. The problem now is that kamailio uses the inbound interface as the outbound socket for messages (I think this is the default, expected, behaviour). If I enable the "mhomed" parameter then I get the following error: ERROR: <core> [forward.c:218]: ERROR: get_out_socket: no socket found ERROR: <core> [forward.c:572]: forward_req: ERROR: cannot forward to af 2, proto 1 no corresponding listening socket ERROR: sl [sl_funcs.c:282]: ERROR: sl_reply_error used: I'm terribly sorry, server error occurred (7/SL) I had a look around on the docuwiki and I found $fs. Would I need to force the outbound socket for each message in this case, or do I have a simple comfiguration issue? Any thoughts/comments would be greatly appreciated. Thanks

6 12

About tm retrans time on ser or kamailio 3.1?
by Min Wang 30 Mar '11

30 Mar '11

HI I did the trace using ngrep: ngrep -T -W byline -d any port 5060 And I am confused with tm retran. (1) case one tm module, the| retr_timer1| default is 500 ms. #U +0.001824 xxx.17:5060 -> xxx.16:5060 INVITE sip:224@172.16.8.49:2057;line=lnzlkxu5 SIP/2.0. #U +0.000012 xxx.17:5060 -> xxx.16:5060 INVITE sip:224@172.16.8.49:2057;line=lnzlkxu5 SIP/2.0. the ngrep show the delta between packet, the second invite is only 12 ms behind? is my understanding correct? (2) change retr_timer1 to 2000 ms modparam("tm", "retr_timer1", 1000) #U +0.001936 xxx.17:5060 -> xxx.16:5060 INVITE sip:224@172.16.8.49:2057;line=lnzlkxu5 SIP/2.0. #U +0.000013 xxx.17:5060 -> xxx.16:5060 INVITE sip:224@172.16.8.49:2057;line=lnzlkxu5 SIP/2.0. the delta still 13 ms behind, so similar to the case 1, The question is: is the second invite the re-trans by tm? If so why it is around 12/13 ms? not the 500 ms or as configured 2000 ms? thanks. Kind regards / Mit freundlichen Grüßen Min Wang

4 5

SIP Communicator renamed to Jitsi
by Daniel-Constantin Mierla 30 Mar '11

30 Mar '11

Hello, I thought it is an useful information to announce here that the SIP Communicator SIP softphone was renamed to Jitsi. There are several pages mentioning Kamailio and SIP Communicator out there, among them our participation to Google Summer of Code 2010 as well as the full SIP SIMPLE Presence configuration with XCAP: * http://asipto.com/u/sp To fetch the latest version of this sip softphone you just go to: * http://www.jitsi.org Btw, Kamailio is participating again in GSoC, the 2011 edition, together with Jitsi project -- I will make another message regarding this subject. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

4 7

any one use multicast for paging ?
by Ming Liu 29 Mar '11

29 Mar '11

Hi, Need help on paging case. The via header has maddr field contains multicast ip address, how does this configure ? And how does sip proxy server react ? Advice would be appreciated. Ming

2 2

Handling Cancel with rewritten To: and From: headers
by Jeremya 29 Mar '11

29 Mar '11

Hi, I have a kamailio 3.1.0 system. I am using mostly the kamailio.cfg script that came with that release but I've made a couple of changes - The pstn.gw_ip bit doesn't work - syntax error - so I've substituted fixed text for now - I've expanded the PSTN section to IN_PSTN and OUT_PSTN to handle outgoing PSTN calls and route PSTN incoming calls to the correct phones. - As (strange) requirement of my SIP trunk provider I've had to rewrite the To: and From: headers on new outgoing PSTN calls The issue I have is with CANCEL. I'm using the default CANCEL handling stanza in kamailio.cfg # CANCEL processing if ( is_method ( "CANCEL" ) ) { if ( t_check_trans() ) t_relay(); exit; } What I see in wireshark is that the From: header is the same as my rewritten version, but the To: header is as provided by the UA This doesn't cause any real problems but I'd like to know what the rules are for kamailio rewriting a CANCEL message - and if required - whether I can rewrite a header in the CANCEL section and not have it 'adjusted' by the internal t_check_trans and t_relay logic? Thanks Jeremy

1 0

Problem with rtpproxy
by Linux Guy 28 Mar '11

28 Mar '11

What could I have done wrong ? I am not able to have kamailio see rtpproxy. I am using kamailio 3.1.2 and rtpproxy 1.2 Rtpproxy is started with command : /usr/local/bin/rtpproxy -l <public ip> -s udp:localhost:7722 -u rtpproxy Module parameter : modparam("rtpproxy", "rtpproxy_sock", "udp:127.0.0.1:7722") Error : INFO: mi_datagram [mi_datagram.c:318]: a new child 0/4170 ERROR: rtpproxy [rtpproxy.c:1517]: timeout waiting reply from a RTP proxy ERROR: rtpproxy [rtpproxy.c:1526]: proxy <udp:public ip:7722> does not respond, disable it WARNING: rtpproxy [rtpproxy.c:1383]: can't get version of the RTP proxy WARNING: rtpproxy [rtpproxy.c:1420]: support for RTP proxy <udp:public ip:7722> has been disabled temporarily Regards, Linux Guy..

4 4

Failure route triggers a 500 internal server error - take 2
by Miguel Baptista 28 Mar '11

28 Mar '11

Hi all, A couple of days ago I sent an identical email but because I wasn't a member of this list I don't know if you got it or not. Additionally, I would like to say that I have the same problem with kamailio 3.1.1. This is very weird problem .. I am using kamailio 3.1.2 (like I say the same is happening with 3.1.1) and I have an issue with failure route. Every-time kamailio enters the failure route an internal error is triggered and kamailio sends a 500 SIP error message: /SIP/2.0 500 I'm terribly sorry, server error occurred (1/TM)/. Just for testing purpose I "downgraded" my failure route configuration to a very simple one. But even so I am always getting the same error and it doesn't matter if it is a busy, a cancel, a moved temporarily... If I don't arm the failure route I don't get any error. Any idea what might be wrong? Is this a bug? This is the relevant part of my configuration : */route[RELAY] {/* / if (is_method("INVITE")) {/ / t_on_failure("FAILTWO");/ / }/ / if (!t_relay()) {/ / sl_reply_error();/ / }/ / exit;/ /}/ /*failure_route[FAILTWO] {* xlog("L_INFO", "FAILUREFROMEXTERNAL: Entered\n"); if (t_check_status("302")) { xlog("L_INFO", "FAILUREFROMEXTERNAL: 302 detected\n"); } else { xlog("L_INFO", "FAILUREFROMEXTERNAL: other detected\n"); } xlog("L_INFO", "FAILUREFROMEXTERNAL: Exiting\n");/ } Here is the Debug output from a busy message got by kamailio and the internal error generated: /Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 860) called from <core>: receive.c: receive_msg(120) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 860) returns address 0x837e300 frag. 0x837e2e8 (size=860) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [parser/msg_parser.c:640]: SIP Reply (status): Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [parser/msg_parser.c:642]: version: <SIP/2.0> Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [parser/msg_parser.c:644]: status: <486> Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [parser/msg_parser.c:646]: reason: <Busy Here> Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 32) called from <core>: parser/msg_parser.c: parse_headers(341) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 32) returns address 0x837f29c frag. 0x837f284 (size=32) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 116) called from <core>: parser/msg_parser.c: get_hdr_field(130) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 116) returns address 0x837e68c frag. 0x837e674 (size=116) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 32) called from <core>: parser/parse_via.c: parse_via(2168) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 32) returns address 0x837f2ec frag. 0x837f2d4 (size=32) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [parser/parse_via.c:1287]: Found param type 232, <branch> = <z9hG4bK54f1.2f69b061.0>; state=16 Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [parser/parse_via.c:2300]: end of header reached, state=5 Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [parser/msg_parser.c:515]: parse_headers: Via found, flags=2 Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [parser/msg_parser.c:517]: parse_headers: this is the first via Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [receive.c:145]: After parse_msg... Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: tm [t_lookup.c:1081]: DEBUG: t_check_msg: msg id=19 global id=18 T start=0xffffffff Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 32) called from <core>: parser/msg_parser.c: parse_headers(341) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 32) returns address 0x837f33c frag. 0x837f324 (size=32) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 116) called from <core>: parser/msg_parser.c: get_hdr_field(130) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 116) returns address 0x837e820 frag. 0x837e808 (size=224) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 32) called from <core>: parser/parse_via.c: parse_via(2168) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 32) returns address 0x837f38c frag. 0x837f374 (size=32) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [parser/parse_via.c:1287]: Found param type 232, <branch> = <z9hG4bK1f04fb19>; state=6 Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 32) called from <core>: parser/parse_via.c: parse_via(2168) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 32) returns address 0x837f6e0 frag. 0x837f6c8 (size=32) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [parser/parse_via.c:1287]: Found param type 235, <rport> = <5060>; state=16 Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [parser/parse_via.c:2300]: end of header reached, state=5 Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [parser/msg_parser.c:515]: parse_headers: Via found, flags=22 Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [parser/msg_parser.c:528]: parse_headers: this is the second via Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 32) called from <core>: parser/msg_parser.c: parse_headers(341) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 32) returns address 0x837f730 frag. 0x837f718 (size=32) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 32) called from <core>: parser/msg_parser.c: parse_headers(341) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 32) returns address 0x837f820 frag. 0x837f808 (size=32) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 224) called from <core>: parser/msg_parser.c: get_hdr_field(170) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 224) returns address 0x837e9c8 frag. 0x837e9b0 (size=224) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 24) called from <core>: parser/parse_to.c: parse_to_param(283) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 24) returns address 0x837e930 frag. 0x837e918 (size=24) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [parser/parse_to.c:174]: DEBUG: add_param: tag=i76l2xu48i Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [parser/parse_to.c:803]: end of header reached, state=29 Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [parser/msg_parser.c:187]: DEBUG: get_hdr_field: <To> [41]; uri=[sip:+4773411459@umb.no] Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [parser/msg_parser.c:189]: DEBUG: to body [<sip:+4773411459@umb.no>] Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 32) called from <core>: parser/msg_parser.c: parse_headers(341) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 32) returns address 0x837f780 frag. 0x837f768 (size=32) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 32) called from <core>: parser/msg_parser.c: parse_headers(341) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 32) returns address 0x837f7d0 frag. 0x837f7b8 (size=32) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 24) called from <core>: parser/msg_parser.c: get_hdr_field(149) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 24) returns address 0x837eb78 frag. 0x837eb60 (size=24) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [parser/msg_parser.c:167]: get_hdr_field: cseq <CSeq>: <102> <INVITE> Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: tm [t_lookup.c:967]: DEBUG: t_reply_matching: hash 8005 label 369858290 branch 0 Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: tm [t_lookup.c:1018]: DEBUG: t_reply_matching: reply matched (T=0xb59ec41c)! Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: tm [t_lookup.c:1150]: DEBUG: t_check_msg: msg id=19 global id=19 T end=0xb59ec41c Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: tm [t_reply.c:2014]: DEBUG: reply_received: org. status uas=180, uac[0]=180 local=0 is_invite=1) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:366]: qm_malloc(0xb5881000, 1010) called from tm: t_msgbuilder.c: build_local_reparse(368) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:406]: qm_malloc(0xb5881000, 1012) returns address 0xb59ed5a0 frag. 0xb59ed588 (size=1012) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:428]: qm_free(0xb5881000, 0xb59ed5a0), called from tm: t_reply.c: reply_received(2064) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:450]: qm_free: freeing frag. 0xb59ed588 alloc'ed from tm: t_msgbuilder.c: build_local_reparse(368) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: tm [t_reply.c:1129]: ->>>>>>>>> T_code=180, new_code=486 Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 43) called from tm: t_reply.c: fake_req(854) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 44) returns address 0x837f8c0 frag. 0x837f8a8 (size=44) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: INFO: <script>: FAILUREFROMEXTERNAL: Entered Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: tm [t_lookup.c:1081]: DEBUG: t_check_msg: msg id=16 global id=16 T start=0xb59ec41c Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: tm [t_lookup.c:1153]: DEBUG: t_check_msg: T already found! Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: tm [tm.c:967]: DEBUG:t_check_status: checked status is <486> Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: INFO: <script>: FAILUREFROMEXTERNAL: other detected Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: INFO: <script>: FAILUREFROMEXTERNAL: Exiting Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:428]: qm_free(0x82bcfe0, 0x837f8c0), called from tm: t_reply.c: free_faked_req(885) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:450]: qm_free: freeing frag. 0x837f8a8 alloc'ed from tm: t_reply.c: fake_req(854) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [msg_translator.c:204]: check_via_address(158.36.141.13, 158.36.141.13, 0) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 12) called from <core>: msg_translator.c: rport_builder(390) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 12) returns address 0x837f008 frag. 0x837eff0 (size=12) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 392) called from <core>: msg_translator.c: build_res_buf_from_sip_req(2032) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 392) returns address 0x838007c frag. 0x8380064 (size=564) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:428]: qm_free(0x82bcfe0, 0x837f008), called from <core>: msg_translator.c: build_res_buf_from_sip_req(2192) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:450]: qm_free: freeing frag. 0x837eff0 alloc'ed from <core>: msg_translator.c: rport_builder(390) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:428]: qm_free(0xb5881000, 0xb59ed29c), called from <core>: mem/shm_mem.c: sh_realloc(82) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:450]: qm_free: freeing frag. 0xb59ed284 alloc'ed from <core>: mem/shm_mem.c: sh_realloc(83) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:366]: qm_malloc(0xb5881000, 391) called from <core>: mem/shm_mem.c: sh_realloc(83) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:406]: qm_malloc(0xb5881000, 392) returns address 0xb59ea720 frag. 0xb59ea708 (size=500) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: tm [t_reply.c:1470]: DEBUG: cleanup_uac_timers: RETR/FR timers reset Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: tm [t_reply.c:659]: DEBUG: reply sent out. buf=0x838007c: SIP/2.0 500 I'm terr..., shmem=0xb59ea720: SIP/2.0 500 I'm terr Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:428]: qm_free(0x82bcfe0, 0x838007c), called from tm: t_reply.c: _reply_light(668) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15015]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 860) called from <core>: receive.c: receive_msg(120) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:450]: qm_free: freeing frag. 0x8380064 alloc'ed from <core>: msg_translator.c: build_res_buf_from_sip_req(2032) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15015]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 860) returns address 0x837e300 frag. 0x837e2e8 (size=860) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: tm [t_reply.c:669]: DEBUG: _reply_light: finished Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15015]: DEBUG: <core> [parser/msg_parser.c:630]: SIP Request: Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: tm [t_reply.c:1631]: DEBUG: relay_reply: branch=0, save=0, relay=-1 Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15015]: DEBUG: <core> [parser/msg_parser.c:632]: method: <ACK> Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: tm [t_reply.c:1470]: DEBUG: cleanup_uac_timers: RETR/FR timers reset Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15015]: DEBUG: <core> [parser/msg_parser.c:634]: uri: <sip:+4773411459@umb.no> Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15015]: DEBUG: <core> [parser/msg_parser.c:636]: version: <SIP/2.0> Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15015]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 32) called from <core>: parser/msg_parser.c: parse_headers(341) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15015]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 32) returns address 0x837ed00 frag. 0x837ece8 (size=32) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15015]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 116) called from <core>: parser/msg_parser.c: get_hdr_field(130) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15015]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 116) returns address 0x837e68c frag. 0x837e674 (size=116) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15015]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 32) called from <core>: parser/parse_via.c: parse_via(2168) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [receive.c:289]: receive_msg: cleaning up Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15015]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 32) returns address 0x837ecb0 frag. 0x837ec98 (size=32) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:428]: qm_free(0x82bcfe0, 0x837f2ec), called from <core>: parser/parse_via.c: free_via_param_list(2387) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15015]: DEBUG: <core> [parser/parse_via.c:1287]: Found param type 232, <branch> = <z9hG4bK1f04fb19>; state=6 Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:450]: qm_free: freeing frag. 0x837f2d4 alloc'ed from <core>: parser/parse_via.c: parse_via(2168) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15015]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 32) called from <core>: parser/parse_via.c: parse_via(2168) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:428]: qm_free(0x82bcfe0, 0x837e68c), called from <core>: parser/parse_via.c: free_via_list(2399) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15015]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 32) returns address 0x837ec60 frag. 0x837ec48 (size=32) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:450]: qm_free: freeing frag. 0x837e674 alloc'ed from <core>: parser/msg_parser.c: get_hdr_field(130) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15015]: DEBUG: <core> [parser/parse_via.c:1287]: Found param type 235, <rport> = <n/a>; state=17 Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:428]: qm_free(0x82bcfe0, 0x837f29c), called from <core>: parser/hf.c: free_hdr_field_lst(251) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15014]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 860) called from <core>: receive.c: receive_msg(120) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15015]: DEBUG: <core> [parser/parse_via.c:2300]: end of header reached, state=5 Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:450]: qm_free: freeing frag. 0x837f284 alloc'ed from <core>: parser/msg_parser.c: parse_headers(341) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15014]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 860) returns address 0x8380078 frag. 0x8380060 (size=860) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15015]: DEBUG: <core> [parser/msg_parser.c:515]: parse_headers: Via found, flags=2 Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:428]: qm_free(0x82bcfe0, 0x837f38c), called from <core>: parser/parse_via.c: free_via_param_list(2387) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15014]: DEBUG: <core> [parser/msg_parser.c:640]: SIP Reply (status): Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15015]: DEBUG: <core> [parser/msg_parser.c:517]: parse_headers: this is the first via Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:450]: qm_free: freeing frag. 0x837f374 alloc'ed from <core>: parser/parse_via.c: parse_via(2168) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15014]: DEBUG: <core> [parser/msg_parser.c:642]: version: <SIP/2.0> Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15015]: DEBUG: <core> [receive.c:145]: After parse_msg... Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:428]: qm_free(0x82bcfe0, 0x837f6e0), called from <core>: parser/parse_via.c: free_via_param_list(2387) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15014]: DEBUG: <core> [parser/msg_parser.c:644]: status: <486> Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15015]: DEBUG: <core> [receive.c:186]: preparing to run routing scripts... Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:450]: qm_free: freeing frag. 0x837f6c8 alloc'ed from <core>: parser/parse_via.c: parse_via(2168) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15014]: DEBUG: <core> [parser/msg_parser.c:646]: reason: <Busy Here> Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15015]: DEBUG: sl [sl_funcs.c:307]: DEBUG : sl_filter_ACK: to late to be a local ACK! / Regards, Miguel Baptista

2 3

Newbie from asterisk
by Sameer Khan 28 Mar '11

28 Mar '11

Hi all I am looking forward to move from asterisk to kamailio, So may be asking some unusual questions My current system is working in such a way that Whenever a call arrives at asterisk i call perl script by AGI and then in that perl script i check customer status, billing, extension routing, updating cdr to my database and many more other operations. The billing which i am doing is different than the one in siremes and i dont want to go for GUI as well So I am looking for a solution similar to AGi. Please direct me to the right path. thanks Sameer.

4 8

problem with dialog module
by Linux Guy 28 Mar '11

28 Mar '11

Dears, I have been trying to use the dialog module to track active calls. I was able to see the active dialogs in database before I implemented IP authentication, now it is not saving the active dialogs to the database. Please provide me some direction. Module parameters : modparam("dialog", "db_url", DBURL) modparam("dialog", "db_mode", 1) modparam("dialog", "dlg_flag", 4) #modparam("dialog", "rr_param", "xyz") modparam("dialog", "dlg_match_mode", 2) modparam("dialog", "timeout_avp","$avp(i:5)") Routing Logic: route(REQINIT); route(NAT); route(WITHINDLG); if (is_method("CANCEL")) { if (t_check_trans()) t_relay(); exit; } t_check_trans(); route(AUTH); # record routing for dialog forming requests (in case they are routed) # - remove preloaded route headers remove_hf("Route"); if (is_method("INVITE|SUBSCRIBE")) record_route(); # account only INVITEs if (is_method("INVITE")) { setflag(FLT_ACC); # do accounting dlg_manage(); setflag(4); } route(PEER); In route(PEER) section, it checks for ip address in the address table and then do the routing based on lcr module. Thank you Linux Guy...

2 1

LCR module : same IP address for different prefix.
by Ricardo Martinez 28 Mar '11

28 Mar '11

Hello. We’re using the LCR module with version 3.1.1 of Kamailio. We’re trying to add two gateways, with the same IP address, we have this configuration running in the previous version of Kamailio (v 1.5), without any problem, but in this version seems to have some issues. This is what I’m trying to do : mysql> select * from lcr_gw; +----+--------+---------+---------------+----------+------+--------+------------+-----------+-------+------+-------+---------+ | id | lcr_id | gw_name | ip_addr | hostname | port | params | uri_scheme | transport | strip | tag | flags | defunct | +----+--------+---------+---------------+----------+------+--------+------------+-----------+-------+------+-------+---------+ | 1 | 1 | GW_1 | 10.0.0.209 | NULL | 5060 | NULL | 1 | 1 | 3 | 303 | 1 | NULL | | 8 | 1 | GW_33 | 10.0.0.209 | NULL | 5060 | NULL | 1 | 1 | 3 | 4411 | 1 | NULL | | 6 | 1 | GW_6 | 10.0.0.212 | NULL | 5060 | NULL | 1 | 1 | 5 | 308 | 1 | NULL | +----+--------+---------+---------------+----------+------+--------+------------+-----------+-------+------+-------+---------+ And this is the output from the logs : /usr/local/sbin/kamailio[2829]: ERROR: lcr [lcr_mod.c:818]: gw <10.0.0.209, 5060, > is not unique What could be the problem?. Os simply the new LCR does not support have two gateways with the same IP address? Thanks, Ricardo Martinez.-

3 9

Fwd: testing kamailio
by michal javorka 28 Mar '11

28 Mar '11

---------- Forwarded message ---------- From: michal javorka <kostriak(a)gmail.com> Date: 2011/3/28 Subject: testing kamailio To: sipp-users(a)lists.sourceforge.net Hi , i am trying to test kamailio 3.1 with sipp testing tool, my topology looks like this: sipp_UAC 158.193.139.120 proxy Kamailio 158.193.139.91 sippsr-users @ lists.sip-router.orgsr-users @ lists.sip-router.org_UAS 158.193.139.107 i am using no authentication and so i just kamctl ul add sipp sip:sipp@158.193.139.120:5060 kamctl ul add 1000 sip:1000@158.193.139.107:5060 commands, so far so good but when i wanted to test it there came troubles on uac i used ./sipp -sn uac 158.193.139.91 -i 158.193.139.120 -s 1000 -r 1 -p 5060 on uas ./sipp -sn uas -i 158.193.139.107 -p 5060 everything looks right but no ACK came from kamailio proxy and i dont know why?? any suggestions? it is part of my bachelor work and i cant move. here is some ngrep from server: interface: eth0 (158.193.139.0/255.255.255.0) filter: (ip or ip6) and ( port 5060 ) U 158.193.139.120:5060 -> 158.193.139.91:5060 INVITE sip:1000@158.193.139.91:5060 SIP/2.0. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-1-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag001. To: sut <sip:1000@158.193.139.91:5060>. Call-ID: 1-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: sip:sipp@158.193.139.120:5060. Max-Forwards: 70. Subject: Performance Test. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.120. s=-. c=IN IP4 158.193.139.120. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 100 trying -- your call is important to us. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-1-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag001. To: sut <sip:1000@158.193.139.91:5060>. Call-ID: 1-636(a)158.193.139.120. CSeq: 1 INVITE. Server: kamailio (3.1.1 (i386/linux)). Content-Length: 0. . U 158.193.139.91:5060 -> 158.193.139.107:5060 INVITE sip:1000@158.193.139.107:5060 SIP/2.0. Record-Route: <sip:158.193.139.91;lr=on>. Via: SIP/2.0/UDP 158.193.139.91;branch=z9hG4bKa21c.7d2fd135.0. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-1-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag001. To: sut <sip:1000@158.193.139.91:5060>. Call-ID: 1-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: sip:sipp@158.193.139.120:5060. Max-Forwards: 69. Subject: Performance Test. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.120. s=-. c=IN IP4 158.193.139.120. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.107:5060 -> 158.193.139.91:5060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 158.193.139.91;branch=z9hG4bKa21c.7d2fd135.0, SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-1-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag001. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag019. Call-ID: 1-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Length: 0. . U 158.193.139.107:5060 -> 158.193.139.91:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 158.193.139.91;branch=z9hG4bKa21c.7d2fd135.0, SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-1-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag001. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag019. Call-ID: 1-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.107. s=-. c=IN IP4 158.193.139.107. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-1-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag001. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag019. Call-ID: 1-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Length: 0. . U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-1-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag001. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag019. Call-ID: 1-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.107. s=-. c=IN IP4 158.193.139.107. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.120:5060 -> 158.193.139.91:5060 ACK sip:1000@158.193.139.91:5060 SIP/2.0. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-1-5. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag001. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag019. Call-ID: 1-636(a)158.193.139.120. CSeq: 1 ACK. Contact: sip:sipp@158.193.139.120:5060. Max-Forwards: 70. Subject: Performance Test. Content-Length: 0. . U 158.193.139.120:5060 -> 158.193.139.91:5060 BYE sip:1000@158.193.139.91:5060 SIP/2.0. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-1-7. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag001. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag019. Call-ID: 1-636(a)158.193.139.120. CSeq: 2 BYE. Contact: sip:sipp@158.193.139.120:5060. Max-Forwards: 70. Subject: Performance Test. Content-Length: 0. . U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 404 Not Here. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-1-7. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag001. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag019. Call-ID: 1-636(a)158.193.139.120. CSeq: 2 BYE. Server: kamailio (3.1.1 (i386/linux)). Content-Length: 0. . U 158.193.139.120:5060 -> 158.193.139.91:5060 BYE sip:1000@158.193.139.91:5060 SIP/2.0. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-1--1. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag001. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag019. Call-ID: 1-636(a)158.193.139.120. CSeq: 3 BYE. Max-Forwards: 70. Contact: <sip:sipp@158.193.139.120:5060;transport=UDP>. Content-Length: 0. . U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 404 Not Here. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-1--1. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag001. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag019. Call-ID: 1-636(a)158.193.139.120. CSeq: 3 BYE. Server: kamailio (3.1.1 (i386/linux)). Content-Length: 0. . U 158.193.139.107:5060 -> 158.193.139.91:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 158.193.139.91;branch=z9hG4bKa21c.7d2fd135.0, SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-1-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag001. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag019. Call-ID: 1-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.107. s=-. c=IN IP4 158.193.139.107. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-1-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag001. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag019. Call-ID: 1-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.107. s=-. c=IN IP4 158.193.139.107. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.120:5060 -> 158.193.139.91:5060 INVITE sip:1000@158.193.139.91:5060 SIP/2.0. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-2-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag002. To: sut <sip:1000@158.193.139.91:5060>. Call-ID: 2-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: sip:sipp@158.193.139.120:5060. Max-Forwards: 70. Subject: Performance Test. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.120. s=-. c=IN IP4 158.193.139.120. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 100 trying -- your call is important to us. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-2-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag002. To: sut <sip:1000@158.193.139.91:5060>. Call-ID: 2-636(a)158.193.139.120. CSeq: 1 INVITE. Server: kamailio (3.1.1 (i386/linux)). Content-Length: 0. . U 158.193.139.91:5060 -> 158.193.139.107:5060 INVITE sip:1000@158.193.139.107:5060 SIP/2.0. Record-Route: <sip:158.193.139.91;lr=on>. Via: SIP/2.0/UDP 158.193.139.91;branch=z9hG4bK4285.21e4a9e7.0. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-2-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag002. To: sut <sip:1000@158.193.139.91:5060>. Call-ID: 2-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: sip:sipp@158.193.139.120:5060. Max-Forwards: 69. Subject: Performance Test. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.120. s=-. c=IN IP4 158.193.139.120. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.107:5060 -> 158.193.139.91:5060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 158.193.139.91;branch=z9hG4bK4285.21e4a9e7.0, SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-2-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag002. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0110. Call-ID: 2-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Length: 0. . U 158.193.139.107:5060 -> 158.193.139.91:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 158.193.139.91;branch=z9hG4bK4285.21e4a9e7.0, SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-2-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag002. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0110. Call-ID: 2-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.107. s=-. c=IN IP4 158.193.139.107. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-2-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag002. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0110. Call-ID: 2-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Length: 0. . U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-2-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag002. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0110. Call-ID: 2-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.107. s=-. c=IN IP4 158.193.139.107. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.120:5060 -> 158.193.139.91:5060 ACK sip:1000@158.193.139.91:5060 SIP/2.0. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-2-5. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag002. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0110. Call-ID: 2-636(a)158.193.139.120. CSeq: 1 ACK. Contact: sip:sipp@158.193.139.120:5060. Max-Forwards: 70. Subject: Performance Test. Content-Length: 0. . U 158.193.139.120:5060 -> 158.193.139.91:5060 BYE sip:1000@158.193.139.91:5060 SIP/2.0. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-2-7. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag002. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0110. Call-ID: 2-636(a)158.193.139.120. CSeq: 2 BYE. Contact: sip:sipp@158.193.139.120:5060. Max-Forwards: 70. Subject: Performance Test. Content-Length: 0. . U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 404 Not Here. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-2-7. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag002. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0110. Call-ID: 2-636(a)158.193.139.120. CSeq: 2 BYE. Server: kamailio (3.1.1 (i386/linux)). Content-Length: 0. . U 158.193.139.120:5060 -> 158.193.139.91:5060 BYE sip:1000@158.193.139.91:5060 SIP/2.0. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-2--1. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag002. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0110. Call-ID: 2-636(a)158.193.139.120. CSeq: 3 BYE. Max-Forwards: 70. Contact: <sip:sipp@158.193.139.120:5060;transport=UDP>. Content-Length: 0. . U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 404 Not Here. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-2--1. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag002. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0110. Call-ID: 2-636(a)158.193.139.120. CSeq: 3 BYE. Server: kamailio (3.1.1 (i386/linux)). Content-Length: 0. . U 158.193.139.107:5060 -> 158.193.139.91:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 158.193.139.91;branch=z9hG4bK4285.21e4a9e7.0, SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-2-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag002. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0110. Call-ID: 2-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.107. s=-. c=IN IP4 158.193.139.107. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-2-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag002. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0110. Call-ID: 2-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.107. s=-. c=IN IP4 158.193.139.107. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.107:5060 -> 158.193.139.91:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 158.193.139.91;branch=z9hG4bKa21c.7d2fd135.0, SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-1-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag001. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag019. Call-ID: 1-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.107. s=-. c=IN IP4 158.193.139.107. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-1-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag001. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag019. Call-ID: 1-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.107. s=-. c=IN IP4 158.193.139.107. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.120:5060 -> 158.193.139.91:5060 INVITE sip:1000@158.193.139.91:5060 SIP/2.0. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-3-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag003. To: sut <sip:1000@158.193.139.91:5060>. Call-ID: 3-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: sip:sipp@158.193.139.120:5060. Max-Forwards: 70. Subject: Performance Test. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.120. s=-. c=IN IP4 158.193.139.120. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 100 trying -- your call is important to us. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-3-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag003. To: sut <sip:1000@158.193.139.91:5060>. Call-ID: 3-636(a)158.193.139.120. CSeq: 1 INVITE. Server: kamailio (3.1.1 (i386/linux)). Content-Length: 0. . U 158.193.139.91:5060 -> 158.193.139.107:5060 INVITE sip:1000@158.193.139.107:5060 SIP/2.0. Record-Route: <sip:158.193.139.91;lr=on>. Via: SIP/2.0/UDP 158.193.139.91;branch=z9hG4bK62b7.0e791b35.0. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-3-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag003. To: sut <sip:1000@158.193.139.91:5060>. Call-ID: 3-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: sip:sipp@158.193.139.120:5060. Max-Forwards: 69. Subject: Performance Test. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.120. s=-. c=IN IP4 158.193.139.120. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.107:5060 -> 158.193.139.91:5060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 158.193.139.91;branch=z9hG4bK62b7.0e791b35.0, SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-3-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag003. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0111. Call-ID: 3-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Length: 0. . U 158.193.139.107:5060 -> 158.193.139.91:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 158.193.139.91;branch=z9hG4bK62b7.0e791b35.0, SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-3-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag003. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0111. Call-ID: 3-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.107. s=-. c=IN IP4 158.193.139.107. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-3-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag003. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0111. Call-ID: 3-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Length: 0. . U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-3-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag003. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0111. Call-ID: 3-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.107. s=-. c=IN IP4 158.193.139.107. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.120:5060 -> 158.193.139.91:5060 ACK sip:1000@158.193.139.91:5060 SIP/2.0. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-3-5. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag003. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0111. Call-ID: 3-636(a)158.193.139.120. CSeq: 1 ACK. Contact: sip:sipp@158.193.139.120:5060. Max-Forwards: 70. Subject: Performance Test. Content-Length: 0. . U 158.193.139.120:5060 -> 158.193.139.91:5060 BYE sip:1000@158.193.139.91:5060 SIP/2.0. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-3-7. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag003. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0111. Call-ID: 3-636(a)158.193.139.120. CSeq: 2 BYE. Contact: sip:sipp@158.193.139.120:5060. Max-Forwards: 70. Subject: Performance Test. Content-Length: 0. . U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 404 Not Here. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-3-7. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag003. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0111. Call-ID: 3-636(a)158.193.139.120. CSeq: 2 BYE. Server: kamailio (3.1.1 (i386/linux)). Content-Length: 0. . U 158.193.139.120:5060 -> 158.193.139.91:5060 BYE sip:1000@158.193.139.91:5060 SIP/2.0. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-3--1. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag003. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0111. Call-ID: 3-636(a)158.193.139.120. CSeq: 3 BYE. Max-Forwards: 70. Contact: <sip:sipp@158.193.139.120:5060;transport=UDP>. Content-Length: 0. . U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 404 Not Here. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-3--1. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag003. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0111. Call-ID: 3-636(a)158.193.139.120. CSeq: 3 BYE. Server: kamailio (3.1.1 (i386/linux)). Content-Length: 0. . U 158.193.139.107:5060 -> 158.193.139.91:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 158.193.139.91;branch=z9hG4bK62b7.0e791b35.0, SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-3-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag003. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0111. Call-ID: 3-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.107. s=-. c=IN IP4 158.193.139.107. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.107:5060 -> 158.193.139.91:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 158.193.139.91;branch=z9hG4bK4285.21e4a9e7.0, SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-2-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag002. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0110. Call-ID: 2-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.107. s=-. c=IN IP4 158.193.139.107. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-3-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag003. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0111. Call-ID: 3-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.107. s=-. c=IN IP4 158.193.139.107. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-2-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag002. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0110. Call-ID: 2-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.107. s=-. c=IN IP4 158.193.139.107. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.120:5060 -> 158.193.139.91:5060 INVITE sip:1000@158.193.139.91:5060 SIP/2.0. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-4-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag004. To: sut <sip:1000@158.193.139.91:5060>. Call-ID: 4-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: sip:sipp@158.193.139.120:5060. Max-Forwards: 70. Subject: Performance Test. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.120. s=-. c=IN IP4 158.193.139.120. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 100 trying -- your call is important to us. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-4-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag004. To: sut <sip:1000@158.193.139.91:5060>. Call-ID: 4-636(a)158.193.139.120. CSeq: 1 INVITE. Server: kamailio (3.1.1 (i386/linux)). Content-Length: 0. . U 158.193.139.91:5060 -> 158.193.139.107:5060 INVITE sip:1000@158.193.139.107:5060 SIP/2.0. Record-Route: <sip:158.193.139.91;lr=on>. Via: SIP/2.0/UDP 158.193.139.91;branch=z9hG4bK1221.c7af9402.0. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-4-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag004. To: sut <sip:1000@158.193.139.91:5060>. Call-ID: 4-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: sip:sipp@158.193.139.120:5060. Max-Forwards: 69. Subject: Performance Test. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.120. s=-. c=IN IP4 158.193.139.120. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.107:5060 -> 158.193.139.91:5060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 158.193.139.91;branch=z9hG4bK1221.c7af9402.0, SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-4-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag004. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0112. Call-ID: 4-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Length: 0. . U 158.193.139.107:5060 -> 158.193.139.91:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 158.193.139.91;branch=z9hG4bK1221.c7af9402.0, SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-4-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag004. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0112. Call-ID: 4-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.107. s=-. c=IN IP4 158.193.139.107. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-4-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag004. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0112. Call-ID: 4-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Length: 0. . U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-4-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag004. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0112. Call-ID: 4-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.107. s=-. c=IN IP4 158.193.139.107. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.120:5060 -> 158.193.139.91:5060 ACK sip:1000@158.193.139.91:5060 SIP/2.0. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-4-5. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag004. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0112. Call-ID: 4-636(a)158.193.139.120. CSeq: 1 ACK. Contact: sip:sipp@158.193.139.120:5060. Max-Forwards: 70. Subject: Performance Test. Content-Length: 0. . U 158.193.139.120:5060 -> 158.193.139.91:5060 BYE sip:1000@158.193.139.91:5060 SIP/2.0. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-4-7. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag004. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0112. Call-ID: 4-636(a)158.193.139.120. CSeq: 2 BYE. Contact: sip:sipp@158.193.139.120:5060. Max-Forwards: 70. Subject: Performance Test. Content-Length: 0. . U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 404 Not Here. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-4-7. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag004. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0112. Call-ID: 4-636(a)158.193.139.120. CSeq: 2 BYE. Server: kamailio (3.1.1 (i386/linux)). Content-Length: 0. . U 158.193.139.120:5060 -> 158.193.139.91:5060 BYE sip:1000@158.193.139.91:5060 SIP/2.0. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-4--1. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag004. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0112. Call-ID: 4-636(a)158.193.139.120. CSeq: 3 BYE. Max-Forwards: 70. Contact: <sip:sipp@158.193.139.120:5060;transport=UDP>. Content-Length: 0. . U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 404 Not Here. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-4--1. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag004. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0112. Call-ID: 4-636(a)158.193.139.120. CSeq: 3 BYE. Server: kamailio (3.1.1 (i386/linux)). Content-Length: 0. . U 158.193.139.107:5060 -> 158.193.139.91:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 158.193.139.91;branch=z9hG4bK1221.c7af9402.0, SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-4-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag004. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0112. Call-ID: 4-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.107. s=-. c=IN IP4 158.193.139.107. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.107:5060 -> 158.193.139.91:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 158.193.139.91;branch=z9hG4bK62b7.0e791b35.0, SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-3-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag003. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0111. Call-ID: 3-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.107. s=-. c=IN IP4 158.193.139.107. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.107:5060 -> 158.193.139.91:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 158.193.139.91;branch=z9hG4bKa21c.7d2fd135.0, SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-1-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag001. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag019. Call-ID: 1-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.107. s=-. c=IN IP4 158.193.139.107. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-1-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag001. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag019. Call-ID: 1-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.107. s=-. c=IN IP4 158.193.139.107. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-4-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag004. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0112. Call-ID: 4-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.107. s=-. c=IN IP4 158.193.139.107. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-3-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag003. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0111. Call-ID: 3-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.107. s=-. c=IN IP4 158.193.139.107. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.120:5060 -> 158.193.139.91:5060 INVITE sip:1000@158.193.139.91:5060 SIP/2.0. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-5-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag005. To: sut <sip:1000@158.193.139.91:5060>. Call-ID: 5-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: sip:sipp@158.193.139.120:5060. Max-Forwards: 70. Subject: Performance Test. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.120. s=-. c=IN IP4 158.193.139.120. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 100 trying -- your call is important to us. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-5-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag005. To: sut <sip:1000@158.193.139.91:5060>. Call-ID: 5-636(a)158.193.139.120. CSeq: 1 INVITE. Server: kamailio (3.1.1 (i386/linux)). Content-Length: 0. . U 158.193.139.91:5060 -> 158.193.139.107:5060 INVITE sip:1000@158.193.139.107:5060 SIP/2.0. Record-Route: <sip:158.193.139.91;lr=on>. Via: SIP/2.0/UDP 158.193.139.91;branch=z9hG4bK3253.0acb5a11.0. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-5-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag005. To: sut <sip:1000@158.193.139.91:5060>. Call-ID: 5-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: sip:sipp@158.193.139.120:5060. Max-Forwards: 69. Subject: Performance Test. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.120. s=-. c=IN IP4 158.193.139.120. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.107:5060 -> 158.193.139.91:5060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 158.193.139.91;branch=z9hG4bK3253.0acb5a11.0, SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-5-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag005. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0113. Call-ID: 5-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Length: 0. . U 158.193.139.107:5060 -> 158.193.139.91:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 158.193.139.91;branch=z9hG4bK3253.0acb5a11.0, SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-5-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag005. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0113. Call-ID: 5-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.107. s=-. c=IN IP4 158.193.139.107. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-5-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag005. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0113. Call-ID: 5-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Length: 0. . U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-5-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag005. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0113. Call-ID: 5-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.107. s=-. c=IN IP4 158.193.139.107. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.120:5060 -> 158.193.139.91:5060 ACK sip:1000@158.193.139.91:5060 SIP/2.0. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-5-5. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag005. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0113. Call-ID: 5-636(a)158.193.139.120. CSeq: 1 ACK. Contact: sip:sipp@158.193.139.120:5060. Max-Forwards: 70. Subject: Performance Test. Content-Length: 0. . U 158.193.139.120:5060 -> 158.193.139.91:5060 BYE sip:1000@158.193.139.91:5060 SIP/2.0. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-5-7. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag005. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0113. Call-ID: 5-636(a)158.193.139.120. CSeq: 2 BYE. Contact: sip:sipp@158.193.139.120:5060. Max-Forwards: 70. Subject: Performance Test. Content-Length: 0. . U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 404 Not Here. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-5-7. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag005. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0113. Call-ID: 5-636(a)158.193.139.120. CSeq: 2 BYE. Server: kamailio (3.1.1 (i386/linux)). Content-Length: 0. . U 158.193.139.120:5060 -> 158.193.139.91:5060 BYE sip:1000@158.193.139.91:5060 SIP/2.0. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-5--1. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag005. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0113. Call-ID: 5-636(a)158.193.139.120. CSeq: 3 BYE. Max-Forwards: 70. Contact: <sip:sipp@158.193.139.120:5060;transport=UDP>. Content-Length: 0. . U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 404 Not Here. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-5--1. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag005. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0113. Call-ID: 5-636(a)158.193.139.120. CSeq: 3 BYE. Server: kamailio (3.1.1 (i386/linux)). Content-Length: 0. . U 158.193.139.107:5060 -> 158.193.139.91:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 158.193.139.91;branch=z9hG4bK1221.c7af9402.0, SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-4-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag004. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0112. Call-ID: 4-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.107. s=-. c=IN IP4 158.193.139.107. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.107:5060 -> 158.193.139.91:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 158.193.139.91;branch=z9hG4bK3253.0acb5a11.0, SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-5-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag005. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0113. Call-ID: 5-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.107. s=-. c=IN IP4 158.193.139.107. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.107:5060 -> 158.193.139.91:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 158.193.139.91;branch=z9hG4bK4285.21e4a9e7.0, SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-2-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag002. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0110. Call-ID: 2-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.107. s=-. c=IN IP4 158.193.139.107. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-5-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag005. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0113. Call-ID: 5-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.107. s=-. c=IN IP4 158.193.139.107. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-2-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag002. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0110. Call-ID: 2-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.107. s=-. c=IN IP4 158.193.139.107. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-4-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag004. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0112. Call-ID: 4-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.107. s=-. c=IN IP4 158.193.139.107. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.120:5060 -> 158.193.139.91:5060 INVITE sip:1000@158.193.139.91:5060 SIP/2.0. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-6-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag006. To: sut <sip:1000@158.193.139.91:5060>. Call-ID: 6-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: sip:sipp@158.193.139.120:5060. Max-Forwards: 70. Subject: Performance Test. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.120. s=-. c=IN IP4 158.193.139.120. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 100 trying -- your call is important to us. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-6-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag006. To: sut <sip:1000@158.193.139.91:5060>. Call-ID: 6-636(a)158.193.139.120. CSeq: 1 INVITE. Server: kamailio (3.1.1 (i386/linux)). Content-Length: 0. . U 158.193.139.91:5060 -> 158.193.139.107:5060 INVITE sip:1000@158.193.139.107:5060 SIP/2.0. Record-Route: <sip:158.193.139.91;lr=on>. Via: SIP/2.0/UDP 158.193.139.91;branch=z9hG4bKd1cc.61efccf5.0. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-6-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag006. To: sut <sip:1000@158.193.139.91:5060>. Call-ID: 6-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: sip:sipp@158.193.139.120:5060. Max-Forwards: 69. Subject: Performance Test. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.120. s=-. c=IN IP4 158.193.139.120. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.107:5060 -> 158.193.139.91:5060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 158.193.139.91;branch=z9hG4bKd1cc.61efccf5.0, SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-6-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag006. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0114. Call-ID: 6-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Length: 0. . U 158.193.139.107:5060 -> 158.193.139.91:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 158.193.139.91;branch=z9hG4bKd1cc.61efccf5.0, SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-6-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag006. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0114. Call-ID: 6-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.107. s=-. c=IN IP4 158.193.139.107. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-6-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag006. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0114. Call-ID: 6-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Length: 0. . U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-6-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag006. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0114. Call-ID: 6-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.107. s=-. c=IN IP4 158.193.139.107. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.120:5060 -> 158.193.139.91:5060 ACK sip:1000@158.193.139.91:5060 SIP/2.0. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-6-5. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag006. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0114. Call-ID: 6-636(a)158.193.139.120. CSeq: 1 ACK. Contact: sip:sipp@158.193.139.120:5060. Max-Forwards: 70. Subject: Performance Test. Content-Length: 0. . U 158.193.139.120:5060 -> 158.193.139.91:5060 BYE sip:1000@158.193.139.91:5060 SIP/2.0. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-6-7. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag006. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0114. Call-ID: 6-636(a)158.193.139.120. CSeq: 2 BYE. Contact: sip:sipp@158.193.139.120:5060. Max-Forwards: 70. Subject: Performance Test. Content-Length: 0. . U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 404 Not Here. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-6-7. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag006. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0114. Call-ID: 6-636(a)158.193.139.120. CSeq: 2 BYE. Server: kamailio (3.1.1 (i386/linux)). Content-Length: 0. . U 158.193.139.120:5060 -> 158.193.139.91:5060 BYE sip:1000@158.193.139.91:5060 SIP/2.0. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-6--1. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag006. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0114. Call-ID: 6-636(a)158.193.139.120. CSeq: 3 BYE. Max-Forwards: 70. Contact: <sip:sipp@158.193.139.120:5060;transport=UDP>. Content-Length: 0. . U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 404 Not Here. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-6--1. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag006. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0114. Call-ID: 6-636(a)158.193.139.120. CSeq: 3 BYE. Server: kamailio (3.1.1 (i386/linux)). Content-Length: 0. . U 158.193.139.107:5060 -> 158.193.139.91:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 158.193.139.91;branch=z9hG4bK3253.0acb5a11.0, SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-5-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag005. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0113. Call-ID: 5-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.107. s=-. c=IN IP4 158.193.139.107. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.107:5060 -> 158.193.139.91:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 158.193.139.91;branch=z9hG4bK62b7.0e791b35.0, SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-3-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag003. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0111. Call-ID: 3-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.107. s=-. c=IN IP4 158.193.139.107. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-5-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag005. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0113. Call-ID: 5-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.107. s=-. c=IN IP4 158.193.139.107. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.107:5060 -> 158.193.139.91:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 158.193.139.91;branch=z9hG4bKd1cc.61efccf5.0, SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-6-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag006. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0114. Call-ID: 6-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.107. s=-. c=IN IP4 158.193.139.107. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-3-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag003. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0111. Call-ID: 3-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.107. s=-. c=IN IP4 158.193.139.107. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-6-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag006. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0114. Call-ID: 6-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.107. s=-. c=IN IP4 158.193.139.107. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.120:5060 -> 158.193.139.91:5060 INVITE sip:1000@158.193.139.91:5060 SIP/2.0. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-7-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag007. To: sut <sip:1000@158.193.139.91:5060>. Call-ID: 7-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: sip:sipp@158.193.139.120:5060. Max-Forwards: 70. Subject: Performance Test. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.120. s=-. c=IN IP4 158.193.139.120. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 100 trying -- your call is important to us. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-7-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag007. To: sut <sip:1000@158.193.139.91:5060>. Call-ID: 7-636(a)158.193.139.120. CSeq: 1 INVITE. Server: kamailio (3.1.1 (i386/linux)). Content-Length: 0. . U 158.193.139.91:5060 -> 158.193.139.107:5060 INVITE sip:1000@158.193.139.107:5060 SIP/2.0. Record-Route: <sip:158.193.139.91;lr=on>. Via: SIP/2.0/UDP 158.193.139.91;branch=z9hG4bKf1fe.ea66e88.0. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-7-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag007. To: sut <sip:1000@158.193.139.91:5060>. Call-ID: 7-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: sip:sipp@158.193.139.120:5060. Max-Forwards: 69. Subject: Performance Test. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.120. s=-. c=IN IP4 158.193.139.120. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.107:5060 -> 158.193.139.91:5060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 158.193.139.91;branch=z9hG4bKf1fe.ea66e88.0, SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-7-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag007. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0115. Call-ID: 7-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Length: 0. . U 158.193.139.107:5060 -> 158.193.139.91:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 158.193.139.91;branch=z9hG4bKf1fe.ea66e88.0, SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-7-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag007. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0115. Call-ID: 7-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.107. s=-. c=IN IP4 158.193.139.107. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-7-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag007. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0115. Call-ID: 7-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Length: 0. . U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-7-0. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag007. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0115. Call-ID: 7-636(a)158.193.139.120. CSeq: 1 INVITE. Contact: <sip:158.193.139.107:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 158.193.139.107. s=-. c=IN IP4 158.193.139.107. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000 U 158.193.139.120:5060 -> 158.193.139.91:5060 ACK sip:1000@158.193.139.91:5060 SIP/2.0. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-7-5. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag007. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0115. Call-ID: 7-636(a)158.193.139.120. CSeq: 1 ACK. Contact: sip:sipp@158.193.139.120:5060. Max-Forwards: 70. Subject: Performance Test. Content-Length: 0. . U 158.193.139.120:5060 -> 158.193.139.91:5060 BYE sip:1000@158.193.139.91:5060 SIP/2.0. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-7-7. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag007. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0115. Call-ID: 7-636(a)158.193.139.120. CSeq: 2 BYE. Contact: sip:sipp@158.193.139.120:5060. Max-Forwards: 70. Subject: Performance Test. Content-Length: 0. . U 158.193.139.91:5060 -> 158.193.139.120:5060 SIP/2.0 404 Not Here. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-7-7. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag007. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0115. Call-ID: 7-636(a)158.193.139.120. CSeq: 2 BYE. Server: kamailio (3.1.1 (i386/linux)). Content-Length: 0. . U 158.193.139.120:5060 -> 158.193.139.91:5060 BYE sip:1000@158.193.139.91:5060 SIP/2.0. Via: SIP/2.0/UDP 158.193.139.120:5060;branch=z9hG4bK-636-7--1. From: sipp <sip:sipp@158.193.139.120:5060>;tag=636SIPpTag007. To: sut <sip:1000@158.193.139.91:5060>;tag=2180SIPpTag0115. Call-ID: 7-636(a)158.193.139.120. CSeq: 3 BYE. Max-Forwards: 70. Contact: <sip:sip... [Správa odseknutá]

1 0

GSoC 2011 mentoring
by Daniel-Constantin Mierla 28 Mar '11

28 Mar '11

Hello, I am again the coordinator for Kamailio's project at GSoC 2011, last year we had very good results with other developers joining the mentoring team. It was the case of Marius Zbihlei that really helped a lot, now being another opportunity to thank him again. If you want to help guiding the implementation of SIP-to-Jingle gateway, please come on board! This means you have to discuss with the selected student and guide him through one of following topics: Kamailio sources, SIP or Jingle. For the Jingle part, which is probably a bit unknown for our community, we can ask the guys at Jitsi project - we are part of the same organization at GSoC 2011. Relevant links to our GSoC participations: http://www.kamailio.org/w/gsoc-2011/ http://www.kamailio.org/w/gsoc-2010/ Thanks, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

1 0

Can't connect/register UA@SER
by SlawKo.skrzynka＠poczta.fm 27 Mar '11

27 Mar '11

> Hello, > > I am trying to set up basic SER configuration ("Hello World" Reference Design from SER-GettingStarted.pdf) but got in trouble at the UA connection. > > My teststbench consist of: > > SER server > IP address: 192.168.2.33 > Hostname: centoshost > OS: CentOS 5.3 > > Workstation with Linphone softphone > IP address: 192.168.2.5 > Hostname: susel > OS: openSUSE 11.2 > > ATA + regular phone > IP address: 192.168.2.191 > > Network switch + cabling > > > I had no problems with SER installation. It also runs correctly (I suppose). > > When SER started with updated ser.cfg according to manual, I couldn't even make basic registrations without any authentication. > > In the next step I added SQL support, hoping to register UA with authentication, but this didn't worked out either. > > So I have looked at ports at server and secured their openess - gave no improvement. > > > I will be glad to receive some hint where to make changes in my system. > > > Below are some commands (with results) I have tried on a server and workstaton. > I use SSH to connect to the server and issue commands there. > > As an attachement I provide ser.cfg file for inspection. > > > > Kind Regards, > > Slawomir > > > > ******************************************** > > [root@centoshost sbin]# cat /etc/*release > CentOS release 5.3 (Final) > > > [root@centoshost ~]# /etc/init.d/mysqld start > Starting MySQL: [ OK ] > [root@centoshost ~]# /etc/init.d/mysqld status > mysqld (pid 2640) is running... > > [root@centoshost ~]# export SIP_DOMAIN="centoshost" > > [root@centoshost sbin]# serctl start > > Starting SER : started pid(2709) > > > [root@centoshost sbin]# serctl moni > > Server: Sip EXpress router (0.9.6 (i386/linux)) ,2xx: 0 > Now: Sun Oct 11 04:56:03 2009 2009 local) ,2xx: 0 > Up Since: Sun Oct 11 04:00:30 2009 local) ,2xx: 0 > Up time: 3333 [sec]ics 0, 5xx: 0, 4xx: 0, 3xx: 0,2xx: 0 > Transaction Statistics Total: 0 (0 local) ,2xx: 0 > Transaction Statistics Total: 0 (0 local) 4xx: 0 > Current: 0 (0 waiting) Total: 0 (0 local) ,2xx: 0 > Replied localy: 0 0, 5xx: 0, 4xx: 0, 3xx: 0,2xx: 0 > Completion status 6xx: 0, 5xx: 0, 4xx: 0, 3xx: 0,2xx: 0 > Stateless Server Statistics 407: 0 408: 0 483: 0 4xx: 0 > Stateless Server Statistics > 200: 0 202: 0 2xx: 0 0 0 408: 0 483: 0 4xx: 0 > 300: 0 301: 0 302: 0 3xx: 0 0 408: 0 483: 0 4xx: 0 > 400: 0 401: 0 403: 0 404: 0 407: 0 408: 0 483: 0 4xx: 0 > 500: 0 5xx: 0 xpired > 6xx: 0 Expired > xxx: 0 Expired > failures: 0 > UsrLoc Statstered Expired > UsrLoc Statstered Expired > Domain Registered Expired > 'aliases' 0 00 > 'location' 0 0 > > [root@centoshost sbin]# serctl ps > 0 2709 attendant > 1 2714 fifo server > 2 2717 receiver child=0 sock= 192.168.2.33:5060 > 3 2719 receiver child=1 sock= 192.168.2.33:5060 > 4 2721 receiver child=2 sock= 192.168.2.33:5060 > 5 2724 receiver child=3 sock= 192.168.2.33:5060 > 6 2727 timer > 7 2730 tcp receiver > 8 2733 tcp receiver > 9 2735 tcp receiver > 10 2739 tcp receiver > 11 2742 tcp main process > > [root@centoshost sbin]# serctl ping 1001(a)192.168.2.191 > 400 > > [root@centoshost sbin]# ping 192.168.2.191 > PING 192.168.2.191 (192.168.2.191) 56(84) bytes of data. > 64 bytes from 192.168.2.191: icmp_seq=1 ttl=250 time=2.77 ms > 64 bytes from 192.168.2.191: icmp_seq=2 ttl=250 time=2.70 ms > 64 bytes from 192.168.2.191: icmp_seq=3 ttl=250 time=1.51 ms > > --- 192.168.2.191 ping statistics --- > 3 packets transmitted, 3 received, 0% packet loss, time 2000ms > rtt min/avg/max/mdev = 1.510/2.330/2.778/0.582 ms > > [root@centoshost sbin]# netstat -an > Active Internet connections (servers and established) > Proto Recv-Q Send-Q Local Address Foreign Address State > tcp 0 0 192.168.2.33:5060 0.0.0.0:* LISTEN > tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN > tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN > tcp 0 0 0.0.0.0:757 0.0.0.0:* LISTEN > tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN > tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN > tcp 0 0 :::22 :::* LISTEN > tcp 0 0 ::ffff:192.168.2.33:22 ::ffff:192.168.2.5:56321 ESTABLISHED > udp 0 300 192.168.2.33:38530 192.168.12.254:53 ESTABLISHED > udp 0 0 192.168.2.33:44954 192.168.2.1:53 ESTABLISHED > udp 0 0 192.168.2.33:5060 0.0.0.0:* > udp 0 0 0.0.0.0:41417 0.0.0.0:* > udp 0 0 0.0.0.0:5353 0.0.0.0:* > udp 0 0 0.0.0.0:751 0.0.0.0:* > udp 0 0 0.0.0.0:111 0.0.0.0:* > udp 0 0 0.0.0.0:754 0.0.0.0:* > udp 0 0 0.0.0.0:631 0.0.0.0:* > udp 0 0 :::41038 :::* > udp 0 0 :::5353 :::* > > mysql> select username, password, domain from subscriber; > +----------+----------+------------+ > | username | password | domain | > +----------+----------+------------+ > | admin | heslo | centoshost | > | 1001 | abc | centoshost | > | 1000 | abc | centoshost | > +----------+----------+------------+ > > > > > **************************** > > susel:/usr/local # cat /etc/*release > LSB_VERSION="core-2.0-noarch:core-3.2-noarch:core-4.0-noarch:core-2.0-ia32:core-3.2-ia32:core-4.0-ia32" > openSUSE 11.2 (i586) > VERSION = 11.2 > > susel:/usr/local # ping 192.168.2.33 > PING 192.168.2.33 (192.168.2.33) 56(84) bytes of data. > 64 bytes from 192.168.2.33: icmp_seq=1 ttl=64 time=0.421 ms > 64 bytes from 192.168.2.33: icmp_seq=2 ttl=64 time=0.400 ms > 64 bytes from 192.168.2.33: icmp_seq=3 ttl=64 time=0.425 ms > ^C > --- 192.168.2.33 ping statistics --- > 3 packets transmitted, 3 received, 0% packet loss, time 1999ms > rtt min/avg/max/mdev = 0.400/0.415/0.425/0.019 ms > > susel:/usr/local # nmap -sS -p1-65535 192.168.2.33 > > Starting Nmap 5.00 ( http://nmap.org ) at 2011-03-21 20:32 CET > Interesting ports on 192.168.2.33: > Not shown: 65530 filtered ports > PORT STATE SERVICE > 22/tcp open ssh > 80/tcp closed http > 443/tcp closed https > 631/tcp closed ipp > 5060/tcp open sip > MAC Address: 08:00:06:0E:E1:FC (Siemens AG) > > Nmap done: 1 IP address (1 host up) scanned in 152.32 seconds > > > > susel:/usr/local # sipsak -vv -s sip:1001@192.168.2.33 > > received ICMP message (type: 3, code: 10): from 192.168.2.33 > > susel:/usr/local # sipsak -vv -s sip:1000@192.168.2.33 > > received ICMP message (type: 3, code: 10): from 192.168.2.33 > > susel:/usr/local # sipsak -T -s sip:1000@192.168.2.33 > warning: IP extract from warning activated to be more informational > (type: 3, code: 10): from 192.168.2.33 > > susel:/usr/local # sipsak -T -s sip:1001@192.168.2.33 > warning: IP extract from warning activated to be more informational > (type: 3, code: 10): from 192.168.2.33 > > susel:/usr/local # sipsak -a --password abc -s sip:1001@192.168.2.33 > (type: 3, code: 10): from 192.168.2.33 > > susel:/usr/local # sipsak -a --password abc -s sip:1000@192.168.2.33 > (type: 3, code: 10): from 192.168.2.33 > ------------------------------------------------- Sily koalicji atakuja rezim. Skomplikowana sytuacja w Libii. Raport » http://linkint.pl/f295a

1 0

Watch algeria 3 TV 29 march at 07:00pm GMT
by Meftah Tayeb 27 Mar '11

27 Mar '11

hi guys, please everyone that have access to Neal SAT or Arab sat try to lookup algeria 3 TV channel and watch it starting from 07:00pm gmt time the TV channel have made a show about me, including my blind / tech life please check;) -- Meftah Tayeb inum: +883510001288000 phone: +13477595883

1 0

Managing SUBSCRIBES
by Spinov Evgeniy 27 Mar '11

27 Mar '11

Hello, everyone. I've got stuck with a small problem with SUBSCRIBES. Let's say we have 2 separate customers with IDs: 1 and 2. They have 2 extenstions each: 1_100, 1_101 and 2_100, 2_101. The task is to subscribe 1_100 to 1_101. When I assign on DSS ( BLF ) key, phone number 1_101, then everything works perfectly, however, I cannot press this DSS key and get connected with 101 as prefix will break the magic. The question is there any workaround for this issue except cutting of the prefix for INVITE requests each time? Or how correctly to implement multi tenant kamailio? Thanks.

1 0

[Kamailio-Users] Rewrite $tU
by Spinov Evgeniy 27 Mar '11

27 Mar '11

>Hello, >with the latest version there are alternatives you can use: >> On 12/10/09 5:06 PM, David wrote: >> Hey, >> >> I won't pretend to be an expert in Kamailio, someone will probably >> suggest a better way. But here is how I rewrote my SIP packet's TO >> header before relaying it to the next hop : >> >> # Rewrite RURI >> avp_printf("$rU", "prefix_$rU"); >$rU = "prefix_" + $rU; >> >> # Remove existing header >> remove_hf("To") ; >> >> # Add new header which is copied from RURI >> insert_hf("To: $ru\r\n", "From"); >you can do in one step, so you avoid operations on r-uri: >insert_hf("To: sip:prefix_$rU@$rd\r\n", "From"); >> >> >> DISCLAIMER : Several threads have said that changing the TO header is >>a bad idea, so I only recommend using this as a last resort. >If devices are RFC3261 (SIP 2.0), then it is ok. If there are SIP 1.0 >devices, then you have to preserve To/From header. >For the future, I would add options to change the From/To values via >pseudo-variables. It is the admin to decide to use it or not -- now >people need and do workarounds with subst or append_hf(). >Cheers, >Daniel I use Kamailio 3.0.3, and tried to use both of methods, i.e. insert_ft() and reassigning pseudo variable $rU and all mentioned in this topic. However, handle_subscribe() and dlg_manage() somewhy uses unmodified packet. Is there any workaround to handle $rU or $tU overwrites that for pua_dialoginfo module? I'm doing it like that: $var(orig_uri) = $rU; $rU = $(fU{re.subst,/(.*)_(.*)/\1/}) + "_" + $rU; if (is_method("INVITE")) { dlg_manage(); } if (is_method("SUBSCRIBE")) { handle_subscribe(); } $rU = $var(orig_uri); However, according to debug messages, NOTIFY's which are coming just after INVITE are still without prefixes, but packets on Asterisk, which is after Kamailio, are coming modified. Please, advice. > > David > > > > > > David a écrit : >> Hey, >> >> I do understand that normally the TO header should not be written, my >> problem is that I am using the presence_dialoginfo module which uses the >> TO header and not the RURI, which means that in order to tell the >> difference between customer A's extension 101 and Customer B's extension >> 101, I rewrite the TO header to add context. >> >> This is actually the ame problem that I started discussing here : >> http://lists.kamailio.org/pipermail/users/2009-August/024316.html >> >> Trouble is I have not had time to work on this since then. >> >> Thanks, >> >> David >> >> Olle E. Johansson a écrit : >>> 10 dec 2009 kl. 15.04 skrev Iñaki Baz Castillo: >>> >>> >>>> El Jueves, 10 de Diciembre de 2009, David escribió: >>>>> Hey, >>>>> >>>>> I need to rewrite the $tU variable on a packet before it is >>>>> relayed. It >>>>> is ok if the change is only on the relayed packet and the $tU >>>>> variable >>>>> change. The important thing is that I modify the To header, it seems >>>>> that rewritting $tU would be the easiest. >>>> $tU is not writable, but just readable. >>>> If you want to change the "To" header you should do some "dirty" >>>> replacing operation (see textops module). >>> >>> This is propably something we need to change and make the To and >>> From headers writable. >>> It's not dirty to change them any more. >>> >>> David: In the original SIP 1.0 protocol the To/From headers was part >>> of the dialog identification, thus you where not allowed to change >>> them in a proxy. THis was kept in RFC3261 - sip v2 - but has been >>> removed in an additional RFC a short while ago (seen from SIP history). >>> >>> Regards, >>> /O >>> _______________________________________________ >>> Kamailio (OpenSER) - Users mailing list >>> Users at lists.kamailio.org >>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users >>> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users >> >> >> >> _______________________________________________ >> Kamailio (OpenSER) - Users mailing list >> Users at lists.kamailio.org >> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users >> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Kamailio (OpenSER) - Users mailing list > Users at 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/

3 10

Presence, RLS, and NAT Traversal
by Peter Dunkley 26 Mar '11

26 Mar '11

Hello, I am using Kamailio and nathelper to connect UAs behind a NAT. However, I want to use presence and RLS in this system as well. The problem I have is that the presence and RLS modules are not nathelper aware and the NOTIFY requests that they generate are targeted at the private network IP address and port of the UA. Has anyone any experience of this? Can anyone help? I had a cunning plan where, in route[NAT], I detected SUBSCRIBE requests that originate from behind a NAT (and do not have myself as the last hop). When I see a request like this I use add_contact_alias(), record_route() and forward it to myself. I then added a handle_ruri_alias() to the WITH_NAT section of route[RELAY]. The theory being that an in-dialog NOTIFY from presence or RLS will use the route-set established by the SUBSCRIBE transaction. This almost works. The presence.winfo NOTIFY from the presence module and the initial presence NOTIFY from the RLS module make it back to the client successfully. However, when this forwarding of the SUBSCRIBE is in place the RLS subscriptions don't happen. I know it is the forward of the SUBSCRIBE that is the trigger behind this problem because simply commenting that out (and allowing the first SUBSCRIBE to get to RLS) makes the RLS subscriptions happen (but in this case the NOTIFYs get back to the client and are 404'd because the request URI is not correct). The only difference between the first SUBSCRIBE and the forwarded SUBSCRIBE is an additional "Via:" header and a "Record-Route:" header. I ran Kamailio with the -E -ddd options and observed that: * modules_k/rls/subscribe.c:rls_get_service_list() is outputting the line "searching document for user sip:@" * This function is called by modules_k/rls/subscribe.c:rls_handle_subscribe() and the output suggests that GET_FROM_PURI(msg)->user and GET_FROM_PURI(msg)->host are empty strings * However, parse_from_header(msg) is called near the top of rls_handle_subscribe() and clearly succeeds to find the "From:" header in the message * As I mentioned above the forwarded SUBSCRIBE is almost identical to the first SUBSCRIBE, and so it does contain a valid "From:" header All I can think of is that Kamailio is becoming confused by the two near-identical SUBSCRIBE requests and that the "cleaning up" of the first (statelessly forwarded) SUBSCRIBE is also "cleaning up" the forwarded SUBSCRIBE that I am currently working with? My route[NAT]: route[NAT] { xlog("L_INFO", "$rm: route[NAT]\n"); #!ifdef WITH_NAT force_rport(); if (nat_uac_test("19") && $si!="MY_REAL_IP" && $si! ="127.0.0.1") { xlog("L_INFO", " Request from NAT'd UAC\n"); if (is_method("REGISTER")) { fix_nated_register(); } else if (is_method("SUBSCRIBE")) { add_contact_alias(); route(RECORD_ROUTE); forward(127.0.0.1, MY_REAL_PORT); exit; } else { fix_nated_contact(); } setflag(FLT_NATS); } #!endif return; } My route[RECORD_ROUTE]: route[RECORD_ROUTE] { # remove preloaded route headers remove_hf("Route"); if (is_method("INVITE|SUBSCRIBE")) record_route(); return; } The start of my route[RELAY]: route[RELAY] { xlog("L_INFO", "$rm: route[RELAY]\n"); #!ifdef WITH_NAT if (check_route_param("nat=yes")) { setbflag(FLB_NATB); } if (isflagset(FLT_NATS) || isbflagset(FLB_NATB)) { route(RTPPROXY); } handle_ruri_alias(); #!endif Regards, Peter -- Peter Dunkley Technical Director Crocodile RCS Ltd

3 8

uri unescape transformation?
by Juha Heinanen 26 Mar '11

26 Mar '11

i could not find a transformation or function to unescape an uri, such as this: sip%3Atest%40test.fi did i miss it or is there a need to write one? -- juha

3 3

uri unescape transformation?
by Juha Heinanen 26 Mar '11

26 Mar '11

i could not find a transformation or function to unescape an uri, such as this: sip%3Atest%40test.fi did i miss it or is there a need to write one? -- juha

3 6

issue: fr_inv_timer_avp in Kamailio 3.1
by Min Wang 26 Mar '11

26 Mar '11

Hi I am trying to use fr_inv_timer_avp like the following in Kamailio 3.1: #!KAMAILIO ... modparam("tm", "fr_inv_timer_avp", "$avp(i:2)") modparam("tm", "fr_inv_timer", 180000) .. $avp(i:2)=10 ... # t_set_fr(10000); ... t_on_failure("failroute"); It seems it is not working. the invite will timeout in 3 min, not 10 seconds. If t_set_fr is used, it is working ( 10 seconds timeout). the t_set_fr issue is it can only accept the constant, not avp. I saw there was a discussion in the april 2010, http://lists.sip-router.org/pipermail/sr-users/2010-April/027101.html Not sure fr_inv_timer_avp has been tested or not in Kamailio 3.0/3.1? A bug or my misuage the fr_inv_timer_avp? thanks -- Kind regards / Mit freundlichen Grüßen Min Wang BASIS AUDIONET North America BASIS AUDIONET * 716 N. Bethlehem Pike - Suite 300 * Lower Gwynedd * PA 19002 * USA Phone +1 215 674 8600 ext 451 Fax +1 215 646 4959 wang(a)basis-audionet.com www.basis-audionet.com Europe BASIS AUDIONET GmbH * Jessenstraße 4 * 22767 Hamburg * Germany Phone +49 40 85 31 14-0 Fax +49 40 85 31 14-33 www.basis-audionet.de Registered: Hamburg HR B 85866 Managing Director: Lutz Schaffhausen, Rüdiger Kaun

3 8

RES: event_route and acc_db_request().
by Alexandre Abreu 26 Mar '11

26 Mar '11

Hi Daniel, Using 'xmlrpc' and 'mi' it works. When I finish this project, I will write a small text explaining the steps I did to make this work. Maybe this will benefit more people from the community. Thank you. Alexandre -----Mensagem original----- De: Daniel-Constantin Mierla [mailto:miconda@gmail.com] Enviada em: quinta-feira, 24 de março de 2011 03:51 Para: Alexandre Abreu Cc: 'SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing List' Assunto: Re: RES: RES: [SR-Users] event_route and acc_db_request(). Hello, the method name is 'mi' then the first parameter is dlg_terminate_dlg and the next parameters are the ones required by the dlg_terminate_dlg. The XMLRPC command 'mi' is to execute commands from the old control interface that we named MI: http://kamailio.org/docs/modules/stable/modules/mi_rpc.html#id2945832 Cheers, Daniel On 3/23/11 4:30 PM, Alexandre Abreu wrote: > Hi Daniel, > > Look the request/reply. > > <...> > <?xml version="1.0" encoding="UTF-8"?>. > <methodCall>. > <methodName>mi dlg_terminate_dlg</methodName>. > <params>. > <param><value><string>065fa668d8485f33</string></value></param>. > </params>. > </methodCall>. > > <...> > <?xml version="1.0"?> > <methodResponse> > <fault> > <value> > <struct> > <member> > <name>faultCode</name> > <value><int>500</int></value> > </member> > <member> > <name>faultString</name> > <value><string>Method Not Found</string></value> </member> </struct> > </value> </fault> </methodResponse> > > This is module xmlrpc handling the POST at route[XMLRPC]. I am not > sure if I understand correctly how you suggested the use of 'mi dlg_terminate_dlg' > command. > > Thanks, > Alexandre > > -----Mensagem original----- > De: Daniel-Constantin Mierla [mailto:miconda@gmail.com] Enviada em: > quarta-feira, 23 de março de 2011 11:10 > Para: Alexandre Abreu > Cc: 'SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - > Users Mailing List' > Assunto: Re: RES: [SR-Users] event_route and acc_db_request(). > > Hello, > > On 3/23/11 2:36 PM, Alexandre Abreu wrote: >> Hello Daniel. >> >> The module being used is 'mi_xmlrpc.so' > ok, this one creates a new process for handling xmlrpc requests. It is > pretty much clear that is very likely what I suspected first time. > > If you have time, try load instead xmlrpc module and use the command > 'mi dlg_terminate_dlg ...". > > Cheers, > Daniel > >> I am using the Carsten's rtpproxy >> patch. RTPPROXY detects the media timeout and send a notification >> through XMLRPC lib with 'dlg_terminate_dlg callid' to Kamailio. After >> that, I configured the event_route to catch the local generated >> requests for accounting these BYEs. >> >> Thanks, >> Alexandre >> >> -----Mensagem original----- >> De: Daniel-Constantin Mierla [mailto:miconda@gmail.com] Enviada em: >> quarta-feira, 23 de março de 2011 10:17 >> Para: Alexandre Abreu >> Cc: 'SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - >> Users Mailing List' >> Assunto: Re: RES: [SR-Users] event_route and acc_db_request(). >> >> Hello, >> >> On 3/23/11 1:44 PM, Alexandre Abreu wrote: >>> Hello Daniel. >>> >>> The BYE is generated by kamctl/xmlrpc (dlg_terminate_dlg). >> is xmlrpc via mi_xmlrpc or via xmlrpc module? >> >> I have to double check, but looks very likely to be the fact that acc >> db connection was not initialized for MI/RPC children processes. >> >> Thanks, >> Daniel >> >>> Alexandre >>> >>> De: Daniel-Constantin Mierla [mailto:miconda@gmail.com] Enviada em: >>> quarta-feira, 23 de março de 2011 04:55 >>> Para: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - >>> Users Mailing List >>> Cc: Alexandre Abreu >>> Assunto: Re: [SR-Users] event_route and acc_db_request(). >>> >>> Hello, >>> >>> On 3/17/11 5:45 PM, Alexandre Abreu wrote: >>> Hello. >>> >>> Why acc_db_request() doesnt work on event_route? >>> >>> I will take a look. >>> >>> Is the BYE generated by dialog timeout or you trigger it by > kamctl/xmlrpc? >>> Cheers, >>> Daniel >>> >>> >>> >>> Mar 17 13:15:44 devel kamailio[25209]: INFO:<script>: Routing >>> locally generated BYE to<sip:2000000@192.168.200.114:9297> >>> Mar 17 13:15:44 devel kamailio[25209]: ERROR:<core> [db.c:421]: >>> invalid parameter value Mar 17 13:15:44 devel kamailio[25209]: ERROR: >>> acc [acc.c:391]: error in use_table Mar 17 13:15:44 devel >>> kamailio[25209]: INFO:<script>: Routing locally generated BYE >>> to<sip:2000001@192.168.200.149:7335> >>> Mar 17 13:15:44 devel kamailio[25209]: ERROR:<core> [db.c:421]: >>> invalid parameter value Mar 17 13:15:44 devel kamailio[25209]: ERROR: >>> acc [acc.c:391]: error in use_table >>> >>> event_route[tm:local-request] { >>> >>> xlog("L_INFO", "Routing locally generated $rm >>> to<$ru>\n"); >>> >>> if (is_method("BYE")) >>> acc_db_request("rtp-timeout", acc); } >>> >>> If I change acc_db_request() to acc_log_request() everything works >>> fine, but this BYE should go to database for accounting purposes. >>> >>> I am using GIT version from Kamailio branch 3.1. >>> >>> From 2008 there is a thread that also demonstrate this problem: >>> >>> http://www.mail-archive.com/users@lists.kamailio.org/msg01411.html >>> >>> Unfortunately, in the archives, theres no solution for that. >>> >>> Regards, >>> Alexandre >>> >>> >>> _______________________________________________ >>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing >>> list sr-users(a)lists.sip-router.org >>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >>> >>> >> -- >> Daniel-Constantin Mierla >> http://www.asipto.com >> > -- > Daniel-Constantin Mierla > http://www.asipto.com > -- Daniel-Constantin Mierla http://www.asipto.com

4 3

Error when using dispatcher module
by Gary Chen 25 Mar '11

25 Mar '11

Kamailio 3.1.2 I am using Kamailio in front of Freeswitch as simple sip router. To do multi-tenant in Freeswitch I created SIP domain (fs2000.ly.net) and used as sip domain inside my sip phone. This domain does not map to any real IP and no entry in our DNS server. If I sent the call directly to Freeswitch, it works fine and registered with Freeswitch. When I tried to go through Kamailio using dispatcher to route the call to freeswitch, I got this error: ERROR: <core> [resolve.c:1540]: ERROR: sip_hostport2su: could not resolve hostname: "fs2000.ly.net" The strange thing is that sometime the call did go through kamailio and registered with freeswitch. Whenever I restart Kamailio, I got above error and then the error went away by itself. Sometime took a minute and sometime took several hours. And sometime the error come back without restart. Does anybody know why? Why dispatcher want to resolve the hostname when it only lookup dispatcher for destination IP? Gary

1 0

kamailio 3.1: rtpproxy_sock multiple rtpproxies not working?
by Min Wang 24 Mar '11

24 Mar '11

hi I have two questions regarding kamailio 3.1 (1) It seems the following format for rtpproxy_sock not working in Kamailio 3.1 modparam("rtpproxy", "rtpproxy_sock", "udp:localhost:12221 udp:localhost:12222") the error is: 0(11881) ERROR: rtpproxy [rtpproxy.c:957]: Name or service not known ////////////////////////// 0(11881) DEBUG: <core> [sr_module.c:871]: DEBUG: init_mod: rtpproxy 0(11881) DEBUG: rtpproxy [rtpproxy.c:531]: url is udp:locahost:22222, len is 18 0(11881) DEBUG: rtpproxy [rtpproxy.c:531]: url is udp:localhost:22222, len is 19 0(11881) DEBUG: <core> [sr_module.c:871]: DEBUG: init_mod: nathelper .... 0(11881) DEBUG: <core> [sr_module.c:828]: DEBUG: init_mod_child (-127): rtpproxy 0(11881) ERROR: rtpproxy [rtpproxy.c:957]: Name or service not known 0(11881) ERROR: <core> [sr_module.c:832]: init_mod_child(): Error while initializing module rtpproxy (/usr/lib/kamailio/modules_k/rtpproxy.so) But if you do the following it is ok modparam("rtpproxy", "rtpproxy_sock","udp:localhost:12221") modparam("rtpproxy", "rtpproxy_sock","udp:localhost:12222") any clue or format changed for rtpproxy_sock? (2) BTW, how do I log stderror into syslog file? -- log_stderror=yes the error will print out in the console, #configure the /etc/syslog.conf for this feature log_facility=LOG_LOCAL1 this log_facility does not log the log_stderror?? Thanks. Kind regards / Mit freundlichen Grüßen Min Wang

2 2

RES: event_route and acc_db_request().
by Alexandre Abreu 24 Mar '11

24 Mar '11

Hello Daniel. The module being used is 'mi_xmlrpc.so' I am using the Carsten's rtpproxy patch. RTPPROXY detects the media timeout and send a notification through XMLRPC lib with 'dlg_terminate_dlg callid' to Kamailio. After that, I configured the event_route to catch the local generated requests for accounting these BYEs. Thanks, Alexandre -----Mensagem original----- De: Daniel-Constantin Mierla [mailto:miconda@gmail.com] Enviada em: quarta-feira, 23 de março de 2011 10:17 Para: Alexandre Abreu Cc: 'SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing List' Assunto: Re: RES: [SR-Users] event_route and acc_db_request(). Hello, On 3/23/11 1:44 PM, Alexandre Abreu wrote: > Hello Daniel. > > The BYE is generated by kamctl/xmlrpc (dlg_terminate_dlg). is xmlrpc via mi_xmlrpc or via xmlrpc module? I have to double check, but looks very likely to be the fact that acc db connection was not initialized for MI/RPC children processes. Thanks, Daniel > Alexandre > > De: Daniel-Constantin Mierla [mailto:miconda@gmail.com] Enviada em: > quarta-feira, 23 de março de 2011 04:55 > Para: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - > Users Mailing List > Cc: Alexandre Abreu > Assunto: Re: [SR-Users] event_route and acc_db_request(). > > Hello, > > On 3/17/11 5:45 PM, Alexandre Abreu wrote: > Hello. > > Why acc_db_request() doesnt work on event_route? > > I will take a look. > > Is the BYE generated by dialog timeout or you trigger it by kamctl/xmlrpc? > > Cheers, > Daniel > > > > Mar 17 13:15:44 devel kamailio[25209]: INFO:<script>: Routing locally > generated BYE to<sip:2000000@192.168.200.114:9297> > Mar 17 13:15:44 devel kamailio[25209]: ERROR:<core> [db.c:421]: > invalid parameter value Mar 17 13:15:44 devel kamailio[25209]: ERROR: > acc [acc.c:391]: error in use_table Mar 17 13:15:44 devel > kamailio[25209]: INFO:<script>: Routing locally generated BYE > to<sip:2000001@192.168.200.149:7335> > Mar 17 13:15:44 devel kamailio[25209]: ERROR:<core> [db.c:421]: > invalid parameter value Mar 17 13:15:44 devel kamailio[25209]: ERROR: > acc [acc.c:391]: error in use_table > > event_route[tm:local-request] { > > xlog("L_INFO", "Routing locally generated $rm to<$ru>\n"); > > if (is_method("BYE")) > acc_db_request("rtp-timeout", acc); } > > If I change acc_db_request() to acc_log_request() everything works > fine, but this BYE should go to database for accounting purposes. > > I am using GIT version from Kamailio branch 3.1. > > From 2008 there is a thread that also demonstrate this problem: > > http://www.mail-archive.com/users@lists.kamailio.org/msg01411.html > > Unfortunately, in the archives, theres no solution for that. > > Regards, > Alexandre > > > _______________________________________________ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing > list sr-users(a)lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > > -- Daniel-Constantin Mierla http://www.asipto.com

2 3

binary name
by Claudio Furrer 24 Mar '11

24 Mar '11

Hello, What is (or should be) the binary main name when using FLAVOUR=ser, FLAVOUR=sip-router or no FLAVOUR specified? I'm getting "ser" as the name whatever I set to FLAVOUR var at compile time. Is it right? (Makefiles.defs says "ser" in these cases but not sure the intention of the sip-router project). I need to know the correct one to make an ebuild package for Gentoo. Thank you for your answers.. Regards, Claudio

3 7

event_route and acc_db_request().
by Alexandre Abreu 23 Mar '11

23 Mar '11

Hello. Why acc_db_request() doesn't work on event_route? Mar 17 13:15:44 devel kamailio[25209]: INFO: <script>: Routing locally generated BYE to <sip:2000000@192.168.200.114:9297> Mar 17 13:15:44 devel kamailio[25209]: ERROR: <core> [db.c:421]: invalid parameter value Mar 17 13:15:44 devel kamailio[25209]: ERROR: acc [acc.c:391]: error in use_table Mar 17 13:15:44 devel kamailio[25209]: INFO: <script>: Routing locally generated BYE to <sip:2000001@192.168.200.149:7335> Mar 17 13:15:44 devel kamailio[25209]: ERROR: <core> [db.c:421]: invalid parameter value Mar 17 13:15:44 devel kamailio[25209]: ERROR: acc [acc.c:391]: error in use_table event_route[tm:local-request] { xlog("L_INFO", "Routing locally generated $rm to <$ru>\n"); if (is_method("BYE")) acc_db_request("rtp-timeout", "acc"); } If I change acc_db_request() to acc_log_request() everything works fine, but this BYE should go to database for accounting purposes. I am using GIT version from Kamailio branch 3.1. >From 2008 there is a thread that also demonstrate this problem: http://www.mail-archive.com/users@lists.kamailio.org/msg01411.html Unfortunately, in the archives, there's no solution for that. Regards, Alexandre

2 3

RES: RTPPROXY timeout patch.
by Alexandre Abreu 23 Mar '11

23 Mar '11

Hi Carsten, Patch applied. It works now. Thanks, Alexandre. -----Mensagem original----- De: kaiserbock2(a)googlemail.com [mailto:kaiserbock2@googlemail.com] Em nome de Carsten Bock Enviada em: terça-feira, 22 de março de 2011 08:00 Para: Alexandre Abreu Cc: sr-users(a)lists.sip-router.org; RTPproxy Development Assunto: Re: RTPPROXY timeout patch. Hi Alexandre, it took quite a lot of searching, but now it's done. It was a general RTPProxy/PThread issue. The problem seems to be, that the PThread is created before the fork of the main process. Then the Thread waits forever... Attached an changed main.c + rtpp_defines.h which modifies this behaviour and starts the Thread after the fork. I will create an according patch and send it to the RTPProxy-Dev-Mailinglist as well. Have fun, Carsten 2011/3/22 Carsten Bock <lists(a)bock.info>: > Hi Alexandre, > > it seem to be a general RTP-Proxy/PThread issue. It seems not to be > related to the XML-RPC notification; the thread, which processes the > timeouts, seems to waits forever... I will check... > > Carsten > > 2011/3/21 Alexandre Abreu <alexandre.abreu(a)redt.com.br>: >> Hi Carsten, >> >> After more testing, I just realized that the notification works only if I >> use "-f" parameter in RTPPROXY. If I omit this parameter (to run in >> background mode), the session timeout but there's no notification sent >> (BYE). Why's that? >> >> Thanks, >> Alexandre. >> >> -----Mensagem original----- >> De: Alexandre Abreu [mailto:alexandre.abreu@redt.com.br] >> Enviada em: quarta-feira, 16 de março de 2011 14:41 >> Para: 'Carsten Bock' >> Cc: 'sr-users(a)lists.sip-router.org' >> Assunto: RES: RTPPROXY timeout patch. >> >> Carsten, >> >> Here it goes: >> >> [root@devel rtpproxy-carsten]# ./rtpproxy -T 10 -f -F -i -l 192.168.200.90 >> -s udp:*:7722 -d DBUG ERR INFO -n tcp:127.0.0.1:7723 >> INFO:main: rtpproxy started, pid 22495 >> rtpproxy: >>> Running Timeout-Process >> >> DBUG:handle_command: received command "22428_8 Uc0,8,101 080b5d23d1603667 >> 192.168.200.114 6380 0073852a;1" >> INFO:handle_command: new session 080b5d23d1603667, tag 0073852a;1 requested, >> type strong >> INFO:handle_command: new session on a port 48662 created, tag 0073852a;1 >> INFO:handle_command: pre-filling caller's address with 192.168.200.114:6380 >> DBUG:doreply: sending reply "22428_8 48662 192.168.200.90" >> DBUG:handle_command: received command "22436_8 Lc0,8,101 080b5d23d1603667 >> 192.168.200.149 7614 0073852a;1 c758967a;1 >> xmlrpc:http://127.0.0.1:8000/RPC2" >> INFO:handle_command: lookup on ports 48662/58604, session timer restarted >> INFO:handle_command: setting custom timeout handler >> (xmlrpc:http://127.0.0.1:8000/RPC2) >> INFO:handle_command: pre-filling callee's address with 192.168.200.149:7614 >> DBUG:doreply: sending reply "22436_8 58604 192.168.200.90" >> INFO:process_rtp: session timeout >> INFO:remove_session: RTP stats: 982 in from callee, 4 in from caller, 986 >> relayed, 0 dropped >> INFO:remove_session: RTCP stats: 5 in from callee, 1 in from caller, 6 >> relayed, 0 dropped >> INFO:remove_session: session on ports 48662/58604 is cleaned up >> ERR:do_timeout_notification: Timeout socket is: èîÈÄÐÊ@ÍÈÄÈÄ`ê >> DBUG:reconnect_timeout_handler: reconnecting timeout socket >> ERR:reconnect_timeout_handler: can't create timeout socket: Address family >> not supported by protocol >> ERR:do_timeout_notification: unable to send timeout notification >> >> Very weird chars in the debug of what Timeout socket is... >> >> But the custom timeout handler are being printed correctly from the config >> file. >> INFO:handle_command: setting custom timeout handler >> (xmlrpc:http://127.0.0.1:8000/RPC2) >> Here I am running CentOS 5.2 32-bit. >> >> Thanks, >> Alexandre >> >> -----Mensagem original----- >> De: kaiserbock2(a)googlemail.com [mailto:kaiserbock2@googlemail.com] Em nome >> de Carsten Bock Enviada em: quarta-feira, 16 de março de 2011 14:18 >> Para: Alexandre Abreu >> Cc: sr-users(a)lists.sip-router.org >> Assunto: Re: RTPPROXY timeout patch. >> >> Hi Alexandre, >> >> My version of RTP-Proxy is following: >> >> bock@bock-tde:~/ims/rtpproxy$ ./rtpproxy -v Basic version: 20040107 >> Extension 20050322: Support for multiple RTP streams and MOH Extension >> 20060704: Support for extra parameter in the V command Extension 20071116: >> Support for RTP re-packetization Extension 20071218: Support for forking >> (copying) RTP stream Extension 20080403: Support for RTP statistics querying >> Extension 20081102: Support for setting codecs in the update/lookup command >> Extension 20081224: Support for session timeout notifications Extension >> 20090810: Support for automatic bridging Extension 20100819: Support for >> timeout notifications using XML-RPC towards Kamailio/sip-router.org >> >> Please find attached a modified rtpp_notify.c file. I have just added some >> tiny debug output in order to see some points. >> Now you should see the following Debug-Outputs: >> >> rtpproxy: >>> Running Timeout-Process >> >> Then the notifier process is running. That would be good. If not, that's the >> reason why it is not working. When the request comes in, you should see the >> following: >> >> INFO:handle_command: setting custom timeout handler >> (xmlrpc:http://localhost:8000/RPC2) >> >> Then the Timeout-Socket was properly set, that would be good as well. >> Now the timeout: >> >> INFO:process_rtp: session timeout >> [...] >> ERR:do_timeout_notification: Timeout socket is: >> xmlrpc:http://localhost:8000/RPC2 >> >> That would be great, because then the Timeout towards the Kamailio should be >> triggerd. >> If these parts are ok, then there must be some issue either in the XML-RPC >> client library or in the communication between the RTP-Proxy and Kamailio. I >> hope you did a trace on the XML-RPC Port both on the RTPproxy and on the >> Kamailio? What distro are you using? My tests were only on Ubuntu and >> Debian, which are quite similar. >> >> Hope we find this issue, >> >> Kind regards, >> Carsten >> >> P.S.: I think i removed that check for the port for testing, that's why my >> version accepted the socket without port... (now i'm using "-n >> tcp:127.0.0.1:9999") >> >> 2011/3/16 Alexandre Abreu <alexandre.abreu(a)redt.com.br>: >>> Carsten, >>> >>> Indeed. Very strange. >>> >>> Are we running the same RTPPROXY version? How can you start using '-n >>> tcp:127.0.0.1' without specifying a port? >>> >>> [root@devel rtpproxy-carsten]# ./rtpproxy -T 10 -f -F -i -l >>> 192.168.200.90 -s udp:*:7722 -d DBUG ERR INFO -n tcp:127.0.0.1 >>> rtpproxy: can't parse host:port in TCP address >>> rtpproxy: can't start notification thread >>> >>> [root@devel rtpproxy-carsten]# ./rtpproxy -T 10 -f -F -i -l >>> 192.168.200.90 -s udp:*:7722 -d DBUG ERR INFO -n tcp:127.0.0.1:7723 >>> INFO:main: rtpproxy started, pid 21169 >>> >>> DBUG:handle_command: received command "17828_9 Uc0,8,101 >>> 4b10ce04de4f8818 >>> 192.168.200.114 6380 9c4b6265;1" >>> INFO:handle_command: new session 4b10ce04de4f8818, tag 9c4b6265;1 >>> requested, type strong >>> INFO:handle_command: new session on a port 43750 created, tag >>> 9c4b6265;1 >>> INFO:handle_command: pre-filling caller's address with >>> 192.168.200.114:6380 >>> DBUG:doreply: sending reply "17828_9 43750 192.168.200.90 " >>> DBUG:handle_command: received command "17847_9 Lc0,8,101 >>> 4b10ce04de4f8818 >>> 192.168.200.149 7386 9c4b6265;1 dd69ab1d;1 >>> xmlrpc:http://localhost:8000/RPC2" >>> INFO:handle_command: lookup on ports 43750/55796, session timer >>> restarted >>> INFO:handle_command: setting custom timeout handler >>> (xmlrpc:http://localhost:8000/RPC2) >>> INFO:handle_command: pre-filling callee's address with >>> 192.168.200.149:7386 >>> DBUG:doreply: sending reply "17847_9 55796 192.168.200.90 " >>> INFO:process_rtp: session timeout >>> INFO:remove_session: RTP stats: 548 in from callee, 5 in from caller, >>> 553 relayed, 0 dropped >>> INFO:remove_session: RTCP stats: 3 in from callee, 1 in from caller, 4 >>> relayed, 0 dropped >>> INFO:remove_session: session on ports 43750/55796 is cleaned up >>> DBUG:reconnect_timeout_handler: reconnecting timeout socket >>> ERR:reconnect_timeout_handler: can't create timeout socket: Address >>> family not supported by protocol >>> ERR:do_timeout_notification: unable to send timeout notification >>> >>> Above the error message. >>> >>> [root@devel ~]# md5sum rtpproxy-carsten.tar.gz >>> c02b1e2ac57d39562e86bcfc4ee592b8 rtpproxy-carsten.tar.gz >>> >>> Thanks, >>> Alexandre. >>> >>> -----Mensagem original----- >>> De: kaiserbock2(a)googlemail.com [mailto:kaiserbock2@googlemail.com] Em >>> nome de Carsten Bock Enviada em: quarta-feira, 16 de março de 2011 >>> 13:03 >>> Para: Alexandre Abreu >>> Cc: sr-users(a)lists.sip-router.org >>> Assunto: Re: RTPPROXY timeout patch. >>> >>> Hi Alexandre, >>> >>> That is strange: >>> >>> I run the RTP-Proxy like this (directly from the TAR-File, i sent you) >>> and Kamailio with attached config-file. >>> >>> bock@bock-tde:~/ims/rtpproxy$ sudo ./rtpproxy -T 10 -f -F -i -l >>> 127.0.0.1 -s udp:*:22222 -d DBUG -n tcp:127.0.0.1 >>> rtpproxy: Timer started. >>> INFO:main: rtpproxy started, pid 4203 >>> [... Kamailio connects to RTP-Proxy...] >>> DBUG:handle_command: received command "4259_8 >>> UAc98,97,99,104,3,0,8,9,96 56f0f83a-5373-46a1-b6f6-9ce2f93e68d5 >>> 195.71.4.203 4008 5371f039-40d0-4944-aae7-6f75071a2f8c;1" >>> INFO:handle_command: new session 56f0f83a-5373-46a1-b6f6-9ce2f93e68d5, >>> tag 5371f039-40d0-4944-aae7-6f75071a2f8c;1 requested, type strong >>> INFO:handle_command: new session on a port 45508 created, tag >>> 5371f039-40d0-4944-aae7-6f75071a2f8c;1 >>> INFO:handle_command: pre-filling caller's address with >>> 195.71.4.203:4008 >>> DBUG:doreply: sending reply "4259_8 45508 127.0.0.1 " >>> DBUG:handle_command: received command "4259_9 LAc98,96 >>> 56f0f83a-5373-46a1-b6f6-9ce2f93e68d5 195.71.4.203 4000 >>> 5371f039-40d0-4944-aae7-6f75071a2f8c;1 >>> 9915df0c-30fc-49c5-aa8a-c86b4242c094;1 >>> xmlrpc:http://localhost:8000/RPC2" >>> INFO:handle_command: lookup on ports 45508/45238, session timer >>> restarted >>> INFO:handle_command: setting custom timeout handler >>> (xmlrpc:http://localhost:8000/RPC2) >>> INFO:handle_command: pre-filling callee's address with >>> 195.71.4.203:4000 >>> DBUG:doreply: sending reply "4259_9 45238 127.0.0.1 " >>> INFO:process_rtp: session timeout >>> ERR:rtpp_notify_schedule: XMLRPC xmlrpc:http://localhost:8000/RPC2 >>> INFO:remove_session: RTP stats: 0 in from callee, 0 in from caller, 0 >>> relayed, 0 dropped >>> INFO:remove_session: RTCP stats: 0 in from callee, 0 in from caller, 0 >>> relayed, 0 dropped >>> INFO:remove_session: session on ports 45508/45238 is cleaned up >>> ERR:do_timeout_notification: Timeout socket: >>> xmlrpc:http://localhost:8000/RPC2 >>> >>> And it works for me: >>> >>> U 2011/03/16 16:50:14.350721 127.0.0.1:5060 -> 127.0.0.1:15061 BYE >>> sip:2@127.0.0.1:15061;ob SIP/2.0. >>> Via: SIP/2.0/UDP 127.0.0.1;branch=z9hG4bK06e9.245e2dd7.0. >>> To: sip:2@localhost;tag=5371f039-40d0-4944-aae7-6f75071a2f8c. >>> From: sip:1@localhost;tag=9915df0c-30fc-49c5-aa8a-c86b4242c094. >>> CSeq: 7905 BYE. >>> Call-ID: 56f0f83a-5373-46a1-b6f6-9ce2f93e68d5. >>> Content-Length: 0. >>> User-Agent: kamailio (3.2.0-dev2 (x86_64/linux)). >>> Max-Forwards: 70. >>> . >>> >>> U 2011/03/16 16:50:14.350801 127.0.0.1:5060 -> 127.0.0.1:15060 BYE >>> sip:1@127.0.0.1:15060;transport=UDP;ob SIP/2.0. >>> Via: SIP/2.0/UDP 127.0.0.1;branch=z9hG4bK06e9.345e2dd7.0. >>> To: sip:1@localhost;tag=9915df0c-30fc-49c5-aa8a-c86b4242c094. >>> From: sip:2@localhost;tag=5371f039-40d0-4944-aae7-6f75071a2f8c. >>> CSeq: 7905 BYE. >>> Call-ID: 56f0f83a-5373-46a1-b6f6-9ce2f93e68d5. >>> Content-Length: 0. >>> User-Agent: kamailio (3.2.0-dev2 (x86_64/linux)). >>> Max-Forwards: 70. >>> . >>> [...] >>> >>> Maybe, you can add some more debug-info from RTP-Proxy... >>> And can you verify, that the RTP-Proxy is not trying to send the request? >>> >>> Kind regards, >>> Carsten >>> >>> 2011/3/16 Alexandre Abreu <alexandre.abreu(a)redt.com.br>: >>>> Hi Carsten, >>>> >>>> Even with your RTPPROXY tarball I was unable to get this working. >>>> Session remains after RTPPROXY timeout. >>>> I am using KAMAILIO 3.1 branch from GIT and as I told you, I moved >>>> the rtpproxy/ from GIT-MASTER to the Kamailio branch (waiting your >> backport). >>> Is >>>> there anything else regarding this feature that should also should be >>> moved >>>> (beyond rtpproxy/)? >>>> >>>> Thanks, >>>> Alexandre >> >> > > > > -- > Carsten Bock > http://www.ng-voice.com > mailto:carsten@ng-voice.com > -- Carsten Bock http://www.ng-voice.com mailto:carsten@ng-voice.com

2 1

Authentication using a PSTN phone
by Miguel Tadeu 23 Mar '11

23 Mar '11

Hi, I have a service that requires a user to authenticate, in order to bill him at the end of the service. I also need real- time check of the balance during a call, in order to signal when the amount is too low to continue the call. Is this possible with SER? Thanx, Miguel Tadeu

2 1

Question about time display in SIREMIS 2.0
by Ricardo Martinez 22 Mar '11

22 Mar '11

Hello. Is there a way to adjust the timezone to display the charts and the logs in the SIREMIS 2.0? I have my linux machine with my local timezone, but the display in the charts and the logs are not in synch with my local time. Thanks in advance. Regards, Ricardo Martinez.-

2 3

ClueCon 2011 Registration Open, Call For Speakers
by Michael Collins 22 Mar '11

22 Mar '11

Greetings fellow open source VoIP users and developers! We are happy to announce that ClueCon 2011 registration is now open. The event will be held August 9-11, 2011 at the Sofitel Hotel in downtown Chicago. Additionally, we are now accepting proposals for speaking topics. If you or your organization would like to speak at ClueCon this year please contact us with your ideas. Visit us at http://www.cluecon.com for additional details on registration, speaking, or sponsorship opportunities. Thank you to all the members of the open source telephony projects who have supported ClueCon over the years. We hope to see you all again this coming August! Michael S Collins ClueCon Team Member http://www.cluecon.com

1 0

Failure route triggers a 500 internal server error
by Miguel Baptista 22 Mar '11

22 Mar '11

Hi all, I am using kamailio 3.1.2 and I have an issue with failure route. Every-time kamailio enters the failure route an internal error is triggered and kamailio sends a 500 SIP error message: /SIP/2.0 500 I'm terribly sorry, server error occurred (1/TM)/. Just for testing purpose I "downgraded" my failure route configuration to a very simple one. But even so I am always getting the same error and it doesn't matter if it is a busy, a cancel, a moved temporarily... If I don't arm the failure route I don't get any error. Any idea what might be wrong? Is this a bug? This is the relevant part of my configuration : */route[RELAY] {/* / if (is_method("INVITE")) {/ / t_on_failure("FAILTWO");/ / }/ / if (!t_relay()) {/ / sl_reply_error();/ / }/ / exit;/ /}/ /*failure_route[FAILTWO] {* xlog("L_INFO", "FAILUREFROMEXTERNAL: Entered\n"); if (t_check_status("302")) { xlog("L_INFO", "FAILUREFROMEXTERNAL: 302 detected\n"); } else { xlog("L_INFO", "FAILUREFROMEXTERNAL: other detected\n"); } xlog("L_INFO", "FAILUREFROMEXTERNAL: Exiting\n");/ } Here is the Debug output from a busy message got by kamailio and the internal error generated: /Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 860) called from <core>: receive.c: receive_msg(120) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 860) returns address 0x837e300 frag. 0x837e2e8 (size=860) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [parser/msg_parser.c:640]: SIP Reply (status): Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [parser/msg_parser.c:642]: version: <SIP/2.0> Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [parser/msg_parser.c:644]: status: <486> Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [parser/msg_parser.c:646]: reason: <Busy Here> Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 32) called from <core>: parser/msg_parser.c: parse_headers(341) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 32) returns address 0x837f29c frag. 0x837f284 (size=32) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 116) called from <core>: parser/msg_parser.c: get_hdr_field(130) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 116) returns address 0x837e68c frag. 0x837e674 (size=116) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 32) called from <core>: parser/parse_via.c: parse_via(2168) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 32) returns address 0x837f2ec frag. 0x837f2d4 (size=32) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [parser/parse_via.c:1287]: Found param type 232, <branch> = <z9hG4bK54f1.2f69b061.0>; state=16 Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [parser/parse_via.c:2300]: end of header reached, state=5 Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [parser/msg_parser.c:515]: parse_headers: Via found, flags=2 Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [parser/msg_parser.c:517]: parse_headers: this is the first via Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [receive.c:145]: After parse_msg... Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: tm [t_lookup.c:1081]: DEBUG: t_check_msg: msg id=19 global id=18 T start=0xffffffff Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 32) called from <core>: parser/msg_parser.c: parse_headers(341) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 32) returns address 0x837f33c frag. 0x837f324 (size=32) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 116) called from <core>: parser/msg_parser.c: get_hdr_field(130) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 116) returns address 0x837e820 frag. 0x837e808 (size=224) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 32) called from <core>: parser/parse_via.c: parse_via(2168) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 32) returns address 0x837f38c frag. 0x837f374 (size=32) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [parser/parse_via.c:1287]: Found param type 232, <branch> = <z9hG4bK1f04fb19>; state=6 Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 32) called from <core>: parser/parse_via.c: parse_via(2168) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 32) returns address 0x837f6e0 frag. 0x837f6c8 (size=32) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [parser/parse_via.c:1287]: Found param type 235, <rport> = <5060>; state=16 Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [parser/parse_via.c:2300]: end of header reached, state=5 Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [parser/msg_parser.c:515]: parse_headers: Via found, flags=22 Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [parser/msg_parser.c:528]: parse_headers: this is the second via Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 32) called from <core>: parser/msg_parser.c: parse_headers(341) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 32) returns address 0x837f730 frag. 0x837f718 (size=32) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 32) called from <core>: parser/msg_parser.c: parse_headers(341) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 32) returns address 0x837f820 frag. 0x837f808 (size=32) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 224) called from <core>: parser/msg_parser.c: get_hdr_field(170) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 224) returns address 0x837e9c8 frag. 0x837e9b0 (size=224) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 24) called from <core>: parser/parse_to.c: parse_to_param(283) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 24) returns address 0x837e930 frag. 0x837e918 (size=24) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [parser/parse_to.c:174]: DEBUG: add_param: tag=i76l2xu48i Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [parser/parse_to.c:803]: end of header reached, state=29 Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [parser/msg_parser.c:187]: DEBUG: get_hdr_field: <To> [41]; uri=[sip:+4773411459@umb.no] Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [parser/msg_parser.c:189]: DEBUG: to body [<sip:+4773411459@umb.no>] Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 32) called from <core>: parser/msg_parser.c: parse_headers(341) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 32) returns address 0x837f780 frag. 0x837f768 (size=32) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 32) called from <core>: parser/msg_parser.c: parse_headers(341) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 32) returns address 0x837f7d0 frag. 0x837f7b8 (size=32) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 24) called from <core>: parser/msg_parser.c: get_hdr_field(149) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 24) returns address 0x837eb78 frag. 0x837eb60 (size=24) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [parser/msg_parser.c:167]: get_hdr_field: cseq <CSeq>: <102> <INVITE> Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: tm [t_lookup.c:967]: DEBUG: t_reply_matching: hash 8005 label 369858290 branch 0 Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: tm [t_lookup.c:1018]: DEBUG: t_reply_matching: reply matched (T=0xb59ec41c)! Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: tm [t_lookup.c:1150]: DEBUG: t_check_msg: msg id=19 global id=19 T end=0xb59ec41c Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: tm [t_reply.c:2014]: DEBUG: reply_received: org. status uas=180, uac[0]=180 local=0 is_invite=1) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:366]: qm_malloc(0xb5881000, 1010) called from tm: t_msgbuilder.c: build_local_reparse(368) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:406]: qm_malloc(0xb5881000, 1012) returns address 0xb59ed5a0 frag. 0xb59ed588 (size=1012) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:428]: qm_free(0xb5881000, 0xb59ed5a0), called from tm: t_reply.c: reply_received(2064) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:450]: qm_free: freeing frag. 0xb59ed588 alloc'ed from tm: t_msgbuilder.c: build_local_reparse(368) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: tm [t_reply.c:1129]: ->>>>>>>>> T_code=180, new_code=486 Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 43) called from tm: t_reply.c: fake_req(854) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 44) returns address 0x837f8c0 frag. 0x837f8a8 (size=44) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: INFO: <script>: FAILUREFROMEXTERNAL: Entered Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: tm [t_lookup.c:1081]: DEBUG: t_check_msg: msg id=16 global id=16 T start=0xb59ec41c Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: tm [t_lookup.c:1153]: DEBUG: t_check_msg: T already found! Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: tm [tm.c:967]: DEBUG:t_check_status: checked status is <486> Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: INFO: <script>: FAILUREFROMEXTERNAL: other detected Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: INFO: <script>: FAILUREFROMEXTERNAL: Exiting Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:428]: qm_free(0x82bcfe0, 0x837f8c0), called from tm: t_reply.c: free_faked_req(885) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:450]: qm_free: freeing frag. 0x837f8a8 alloc'ed from tm: t_reply.c: fake_req(854) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [msg_translator.c:204]: check_via_address(158.36.141.13, 158.36.141.13, 0) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 12) called from <core>: msg_translator.c: rport_builder(390) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 12) returns address 0x837f008 frag. 0x837eff0 (size=12) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 392) called from <core>: msg_translator.c: build_res_buf_from_sip_req(2032) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 392) returns address 0x838007c frag. 0x8380064 (size=564) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:428]: qm_free(0x82bcfe0, 0x837f008), called from <core>: msg_translator.c: build_res_buf_from_sip_req(2192) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:450]: qm_free: freeing frag. 0x837eff0 alloc'ed from <core>: msg_translator.c: rport_builder(390) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:428]: qm_free(0xb5881000, 0xb59ed29c), called from <core>: mem/shm_mem.c: sh_realloc(82) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:450]: qm_free: freeing frag. 0xb59ed284 alloc'ed from <core>: mem/shm_mem.c: sh_realloc(83) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:366]: qm_malloc(0xb5881000, 391) called from <core>: mem/shm_mem.c: sh_realloc(83) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:406]: qm_malloc(0xb5881000, 392) returns address 0xb59ea720 frag. 0xb59ea708 (size=500) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: tm [t_reply.c:1470]: DEBUG: cleanup_uac_timers: RETR/FR timers reset Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: tm [t_reply.c:659]: DEBUG: reply sent out. buf=0x838007c: SIP/2.0 500 I'm terr..., shmem=0xb59ea720: SIP/2.0 500 I'm terr Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:428]: qm_free(0x82bcfe0, 0x838007c), called from tm: t_reply.c: _reply_light(668) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15015]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 860) called from <core>: receive.c: receive_msg(120) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:450]: qm_free: freeing frag. 0x8380064 alloc'ed from <core>: msg_translator.c: build_res_buf_from_sip_req(2032) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15015]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 860) returns address 0x837e300 frag. 0x837e2e8 (size=860) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: tm [t_reply.c:669]: DEBUG: _reply_light: finished Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15015]: DEBUG: <core> [parser/msg_parser.c:630]: SIP Request: Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: tm [t_reply.c:1631]: DEBUG: relay_reply: branch=0, save=0, relay=-1 Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15015]: DEBUG: <core> [parser/msg_parser.c:632]: method: <ACK> Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: tm [t_reply.c:1470]: DEBUG: cleanup_uac_timers: RETR/FR timers reset Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15015]: DEBUG: <core> [parser/msg_parser.c:634]: uri: <sip:+4773411459@umb.no> Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15015]: DEBUG: <core> [parser/msg_parser.c:636]: version: <SIP/2.0> Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15015]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 32) called from <core>: parser/msg_parser.c: parse_headers(341) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15015]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 32) returns address 0x837ed00 frag. 0x837ece8 (size=32) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15015]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 116) called from <core>: parser/msg_parser.c: get_hdr_field(130) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15015]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 116) returns address 0x837e68c frag. 0x837e674 (size=116) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15015]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 32) called from <core>: parser/parse_via.c: parse_via(2168) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: DEBUG: <core> [receive.c:289]: receive_msg: cleaning up Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15015]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 32) returns address 0x837ecb0 frag. 0x837ec98 (size=32) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:428]: qm_free(0x82bcfe0, 0x837f2ec), called from <core>: parser/parse_via.c: free_via_param_list(2387) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15015]: DEBUG: <core> [parser/parse_via.c:1287]: Found param type 232, <branch> = <z9hG4bK1f04fb19>; state=6 Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:450]: qm_free: freeing frag. 0x837f2d4 alloc'ed from <core>: parser/parse_via.c: parse_via(2168) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15015]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 32) called from <core>: parser/parse_via.c: parse_via(2168) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:428]: qm_free(0x82bcfe0, 0x837e68c), called from <core>: parser/parse_via.c: free_via_list(2399) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15015]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 32) returns address 0x837ec60 frag. 0x837ec48 (size=32) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:450]: qm_free: freeing frag. 0x837e674 alloc'ed from <core>: parser/msg_parser.c: get_hdr_field(130) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15015]: DEBUG: <core> [parser/parse_via.c:1287]: Found param type 235, <rport> = <n/a>; state=17 Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:428]: qm_free(0x82bcfe0, 0x837f29c), called from <core>: parser/hf.c: free_hdr_field_lst(251) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15014]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bcfe0, 860) called from <core>: receive.c: receive_msg(120) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15015]: DEBUG: <core> [parser/parse_via.c:2300]: end of header reached, state=5 Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:450]: qm_free: freeing frag. 0x837f284 alloc'ed from <core>: parser/msg_parser.c: parse_headers(341) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15014]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bcfe0, 860) returns address 0x8380078 frag. 0x8380060 (size=860) on 1 -th hit Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15015]: DEBUG: <core> [parser/msg_parser.c:515]: parse_headers: Via found, flags=2 Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:428]: qm_free(0x82bcfe0, 0x837f38c), called from <core>: parser/parse_via.c: free_via_param_list(2387) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15014]: DEBUG: <core> [parser/msg_parser.c:640]: SIP Reply (status): Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15015]: DEBUG: <core> [parser/msg_parser.c:517]: parse_headers: this is the first via Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:450]: qm_free: freeing frag. 0x837f374 alloc'ed from <core>: parser/parse_via.c: parse_via(2168) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15014]: DEBUG: <core> [parser/msg_parser.c:642]: version: <SIP/2.0> Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15015]: DEBUG: <core> [receive.c:145]: After parse_msg... Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:428]: qm_free(0x82bcfe0, 0x837f6e0), called from <core>: parser/parse_via.c: free_via_param_list(2387) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15014]: DEBUG: <core> [parser/msg_parser.c:644]: status: <486> Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15015]: DEBUG: <core> [receive.c:186]: preparing to run routing scripts... Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15016]: <core> [mem/q_malloc.c:450]: qm_free: freeing frag. 0x837f6c8 alloc'ed from <core>: parser/parse_via.c: parse_via(2168) Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15014]: DEBUG: <core> [parser/msg_parser.c:646]: reason: <Busy Here> Mar 22 13:48:57 sip /usr/ipbx/kamailio/sbin/kamailio[15015]: DEBUG: sl [sl_funcs.c:307]: DEBUG : sl_filter_ACK: to late to be a local ACK! / Regards, Miguel Baptista <javascript:void(0);>

2 1

RES: event_route and acc_db_request().
by Alexandre Abreu 22 Mar '11

22 Mar '11

Hello. I have found another important thread "Catching internally generated BYE event & other" regarding this goal. Alex, Do you mind to share how did you catch the internally generated BYE? (by just reading the thread I can't know if you really did) As far as I understand, the event_route could be used for this (accounting) but specially acc_db_request() does not seem to work. Maybe I am missing something basic or there is other approach to reach this target. Thanks for any tip, Alexandre. De: Alexandre Abreu [mailto:alexandre.abreu@redt.com.br] Enviada em: quinta-feira, 17 de março de 2011 13:45 Para: sr-users(a)lists.sip-router.org Assunto: event_route and acc_db_request(). Hello. Why acc_db_request() doesnt work on event_route? Mar 17 13:15:44 devel kamailio[25209]: INFO: <script>: Routing locally generated BYE to <sip:2000000@192.168.200.114:9297> Mar 17 13:15:44 devel kamailio[25209]: ERROR: <core> [db.c:421]: invalid parameter value Mar 17 13:15:44 devel kamailio[25209]: ERROR: acc [acc.c:391]: error in use_table Mar 17 13:15:44 devel kamailio[25209]: INFO: <script>: Routing locally generated BYE to <sip:2000001@192.168.200.149:7335> Mar 17 13:15:44 devel kamailio[25209]: ERROR: <core> [db.c:421]: invalid parameter value Mar 17 13:15:44 devel kamailio[25209]: ERROR: acc [acc.c:391]: error in use_table event_route[tm:local-request] { xlog("L_INFO", "Routing locally generated $rm to <$ru>\n"); if (is_method("BYE")) acc_db_request("rtp-timeout", acc); } If I change acc_db_request() to acc_log_request() everything works fine, but this BYE should go to database for accounting purposes. I am using GIT version from Kamailio branch 3.1. >From 2008 there is a thread that also demonstrate this problem: http://www.mail-archive.com/users@lists.kamailio.org/msg01411.html Unfortunately, in the archives, theres no solution for that. Regards, Alexandre

1 0

RES: RTPPROXY timeout patch.
by Alexandre Abreu 22 Mar '11

22 Mar '11

Hi Carsten, After more testing, I just realized that the notification works only if I use "-f" parameter in RTPPROXY. If I omit this parameter (to run in background mode), the session timeout but there's no notification sent (BYE). Why's that? Thanks, Alexandre. -----Mensagem original----- De: Alexandre Abreu [mailto:alexandre.abreu@redt.com.br] Enviada em: quarta-feira, 16 de março de 2011 14:41 Para: 'Carsten Bock' Cc: 'sr-users(a)lists.sip-router.org' Assunto: RES: RTPPROXY timeout patch. Carsten, Here it goes: [root@devel rtpproxy-carsten]# ./rtpproxy -T 10 -f -F -i -l 192.168.200.90 -s udp:*:7722 -d DBUG ERR INFO -n tcp:127.0.0.1:7723 INFO:main: rtpproxy started, pid 22495 rtpproxy: >>> Running Timeout-Process DBUG:handle_command: received command "22428_8 Uc0,8,101 080b5d23d1603667 192.168.200.114 6380 0073852a;1" INFO:handle_command: new session 080b5d23d1603667, tag 0073852a;1 requested, type strong INFO:handle_command: new session on a port 48662 created, tag 0073852a;1 INFO:handle_command: pre-filling caller's address with 192.168.200.114:6380 DBUG:doreply: sending reply "22428_8 48662 192.168.200.90" DBUG:handle_command: received command "22436_8 Lc0,8,101 080b5d23d1603667 192.168.200.149 7614 0073852a;1 c758967a;1 xmlrpc:http://127.0.0.1:8000/RPC2" INFO:handle_command: lookup on ports 48662/58604, session timer restarted INFO:handle_command: setting custom timeout handler (xmlrpc:http://127.0.0.1:8000/RPC2) INFO:handle_command: pre-filling callee's address with 192.168.200.149:7614 DBUG:doreply: sending reply "22436_8 58604 192.168.200.90" INFO:process_rtp: session timeout INFO:remove_session: RTP stats: 982 in from callee, 4 in from caller, 986 relayed, 0 dropped INFO:remove_session: RTCP stats: 5 in from callee, 1 in from caller, 6 relayed, 0 dropped INFO:remove_session: session on ports 48662/58604 is cleaned up ERR:do_timeout_notification: Timeout socket is: èîÈÄÐÊ@ÍÈÄÈÄ`ê DBUG:reconnect_timeout_handler: reconnecting timeout socket ERR:reconnect_timeout_handler: can't create timeout socket: Address family not supported by protocol ERR:do_timeout_notification: unable to send timeout notification Very weird chars in the debug of what Timeout socket is... But the custom timeout handler are being printed correctly from the config file. INFO:handle_command: setting custom timeout handler (xmlrpc:http://127.0.0.1:8000/RPC2) Here I am running CentOS 5.2 32-bit. Thanks, Alexandre -----Mensagem original----- De: kaiserbock2(a)googlemail.com [mailto:kaiserbock2@googlemail.com] Em nome de Carsten Bock Enviada em: quarta-feira, 16 de março de 2011 14:18 Para: Alexandre Abreu Cc: sr-users(a)lists.sip-router.org Assunto: Re: RTPPROXY timeout patch. Hi Alexandre, My version of RTP-Proxy is following: bock@bock-tde:~/ims/rtpproxy$ ./rtpproxy -v Basic version: 20040107 Extension 20050322: Support for multiple RTP streams and MOH Extension 20060704: Support for extra parameter in the V command Extension 20071116: Support for RTP re-packetization Extension 20071218: Support for forking (copying) RTP stream Extension 20080403: Support for RTP statistics querying Extension 20081102: Support for setting codecs in the update/lookup command Extension 20081224: Support for session timeout notifications Extension 20090810: Support for automatic bridging Extension 20100819: Support for timeout notifications using XML-RPC towards Kamailio/sip-router.org Please find attached a modified rtpp_notify.c file. I have just added some tiny debug output in order to see some points. Now you should see the following Debug-Outputs: rtpproxy: >>> Running Timeout-Process Then the notifier process is running. That would be good. If not, that's the reason why it is not working. When the request comes in, you should see the following: INFO:handle_command: setting custom timeout handler (xmlrpc:http://localhost:8000/RPC2) Then the Timeout-Socket was properly set, that would be good as well. Now the timeout: INFO:process_rtp: session timeout [...] ERR:do_timeout_notification: Timeout socket is: xmlrpc:http://localhost:8000/RPC2 That would be great, because then the Timeout towards the Kamailio should be triggerd. If these parts are ok, then there must be some issue either in the XML-RPC client library or in the communication between the RTP-Proxy and Kamailio. I hope you did a trace on the XML-RPC Port both on the RTPproxy and on the Kamailio? What distro are you using? My tests were only on Ubuntu and Debian, which are quite similar. Hope we find this issue, Kind regards, Carsten P.S.: I think i removed that check for the port for testing, that's why my version accepted the socket without port... (now i'm using "-n tcp:127.0.0.1:9999") 2011/3/16 Alexandre Abreu <alexandre.abreu(a)redt.com.br>: > Carsten, > > Indeed. Very strange. > > Are we running the same RTPPROXY version? How can you start using '-n > tcp:127.0.0.1' without specifying a port? > > [root@devel rtpproxy-carsten]# ./rtpproxy -T 10 -f -F -i -l > 192.168.200.90 -s udp:*:7722 -d DBUG ERR INFO -n tcp:127.0.0.1 > rtpproxy: can't parse host:port in TCP address > rtpproxy: can't start notification thread > > [root@devel rtpproxy-carsten]# ./rtpproxy -T 10 -f -F -i -l > 192.168.200.90 -s udp:*:7722 -d DBUG ERR INFO -n tcp:127.0.0.1:7723 > INFO:main: rtpproxy started, pid 21169 > > DBUG:handle_command: received command "17828_9 Uc0,8,101 > 4b10ce04de4f8818 > 192.168.200.114 6380 9c4b6265;1" > INFO:handle_command: new session 4b10ce04de4f8818, tag 9c4b6265;1 > requested, type strong > INFO:handle_command: new session on a port 43750 created, tag > 9c4b6265;1 > INFO:handle_command: pre-filling caller's address with > 192.168.200.114:6380 > DBUG:doreply: sending reply "17828_9 43750 192.168.200.90 " > DBUG:handle_command: received command "17847_9 Lc0,8,101 > 4b10ce04de4f8818 > 192.168.200.149 7386 9c4b6265;1 dd69ab1d;1 > xmlrpc:http://localhost:8000/RPC2" > INFO:handle_command: lookup on ports 43750/55796, session timer > restarted > INFO:handle_command: setting custom timeout handler > (xmlrpc:http://localhost:8000/RPC2) > INFO:handle_command: pre-filling callee's address with > 192.168.200.149:7386 > DBUG:doreply: sending reply "17847_9 55796 192.168.200.90 " > INFO:process_rtp: session timeout > INFO:remove_session: RTP stats: 548 in from callee, 5 in from caller, > 553 relayed, 0 dropped > INFO:remove_session: RTCP stats: 3 in from callee, 1 in from caller, 4 > relayed, 0 dropped > INFO:remove_session: session on ports 43750/55796 is cleaned up > DBUG:reconnect_timeout_handler: reconnecting timeout socket > ERR:reconnect_timeout_handler: can't create timeout socket: Address > family not supported by protocol > ERR:do_timeout_notification: unable to send timeout notification > > Above the error message. > > [root@devel ~]# md5sum rtpproxy-carsten.tar.gz > c02b1e2ac57d39562e86bcfc4ee592b8 rtpproxy-carsten.tar.gz > > Thanks, > Alexandre. > > -----Mensagem original----- > De: kaiserbock2(a)googlemail.com [mailto:kaiserbock2@googlemail.com] Em > nome de Carsten Bock Enviada em: quarta-feira, 16 de março de 2011 > 13:03 > Para: Alexandre Abreu > Cc: sr-users(a)lists.sip-router.org > Assunto: Re: RTPPROXY timeout patch. > > Hi Alexandre, > > That is strange: > > I run the RTP-Proxy like this (directly from the TAR-File, i sent you) > and Kamailio with attached config-file. > > bock@bock-tde:~/ims/rtpproxy$ sudo ./rtpproxy -T 10 -f -F -i -l > 127.0.0.1 -s udp:*:22222 -d DBUG -n tcp:127.0.0.1 > rtpproxy: Timer started. > INFO:main: rtpproxy started, pid 4203 > [... Kamailio connects to RTP-Proxy...] > DBUG:handle_command: received command "4259_8 > UAc98,97,99,104,3,0,8,9,96 56f0f83a-5373-46a1-b6f6-9ce2f93e68d5 > 195.71.4.203 4008 5371f039-40d0-4944-aae7-6f75071a2f8c;1" > INFO:handle_command: new session 56f0f83a-5373-46a1-b6f6-9ce2f93e68d5, > tag 5371f039-40d0-4944-aae7-6f75071a2f8c;1 requested, type strong > INFO:handle_command: new session on a port 45508 created, tag > 5371f039-40d0-4944-aae7-6f75071a2f8c;1 > INFO:handle_command: pre-filling caller's address with > 195.71.4.203:4008 > DBUG:doreply: sending reply "4259_8 45508 127.0.0.1 " > DBUG:handle_command: received command "4259_9 LAc98,96 > 56f0f83a-5373-46a1-b6f6-9ce2f93e68d5 195.71.4.203 4000 > 5371f039-40d0-4944-aae7-6f75071a2f8c;1 > 9915df0c-30fc-49c5-aa8a-c86b4242c094;1 > xmlrpc:http://localhost:8000/RPC2" > INFO:handle_command: lookup on ports 45508/45238, session timer > restarted > INFO:handle_command: setting custom timeout handler > (xmlrpc:http://localhost:8000/RPC2) > INFO:handle_command: pre-filling callee's address with > 195.71.4.203:4000 > DBUG:doreply: sending reply "4259_9 45238 127.0.0.1 " > INFO:process_rtp: session timeout > ERR:rtpp_notify_schedule: XMLRPC xmlrpc:http://localhost:8000/RPC2 > INFO:remove_session: RTP stats: 0 in from callee, 0 in from caller, 0 > relayed, 0 dropped > INFO:remove_session: RTCP stats: 0 in from callee, 0 in from caller, 0 > relayed, 0 dropped > INFO:remove_session: session on ports 45508/45238 is cleaned up > ERR:do_timeout_notification: Timeout socket: > xmlrpc:http://localhost:8000/RPC2 > > And it works for me: > > U 2011/03/16 16:50:14.350721 127.0.0.1:5060 -> 127.0.0.1:15061 BYE > sip:2@127.0.0.1:15061;ob SIP/2.0. > Via: SIP/2.0/UDP 127.0.0.1;branch=z9hG4bK06e9.245e2dd7.0. > To: sip:2@localhost;tag=5371f039-40d0-4944-aae7-6f75071a2f8c. > From: sip:1@localhost;tag=9915df0c-30fc-49c5-aa8a-c86b4242c094. > CSeq: 7905 BYE. > Call-ID: 56f0f83a-5373-46a1-b6f6-9ce2f93e68d5. > Content-Length: 0. > User-Agent: kamailio (3.2.0-dev2 (x86_64/linux)). > Max-Forwards: 70. > . > > U 2011/03/16 16:50:14.350801 127.0.0.1:5060 -> 127.0.0.1:15060 BYE > sip:1@127.0.0.1:15060;transport=UDP;ob SIP/2.0. > Via: SIP/2.0/UDP 127.0.0.1;branch=z9hG4bK06e9.345e2dd7.0. > To: sip:1@localhost;tag=9915df0c-30fc-49c5-aa8a-c86b4242c094. > From: sip:2@localhost;tag=5371f039-40d0-4944-aae7-6f75071a2f8c. > CSeq: 7905 BYE. > Call-ID: 56f0f83a-5373-46a1-b6f6-9ce2f93e68d5. > Content-Length: 0. > User-Agent: kamailio (3.2.0-dev2 (x86_64/linux)). > Max-Forwards: 70. > . > [...] > > Maybe, you can add some more debug-info from RTP-Proxy... > And can you verify, that the RTP-Proxy is not trying to send the request? > > Kind regards, > Carsten > > 2011/3/16 Alexandre Abreu <alexandre.abreu(a)redt.com.br>: >> Hi Carsten, >> >> Even with your RTPPROXY tarball I was unable to get this working. >> Session remains after RTPPROXY timeout. >> I am using KAMAILIO 3.1 branch from GIT and as I told you, I moved >> the rtpproxy/ from GIT-MASTER to the Kamailio branch (waiting your backport). > Is >> there anything else regarding this feature that should also should be > moved >> (beyond rtpproxy/)? >> >> Thanks, >> Alexandre

2 2

$rU isn't used in t_relay() in failure_route
by Steven Wheeler 21 Mar '11

21 Mar '11

I am attempting to put together code which will allow us to redirect a call to a different tn if the route failed. Example: User dials 11235551234 Kamailio uses LCR to route to 192.168.0.100 (404 error) Change $rU to 11235550000 in failure_route The only way I can get $rU to show up in the SIP message is to call append_branch() which is not a solution because I now end up with two SIP messages one that is correct and one that is incorrect. Here is the failure_route I am using. Any input would be appreciated. failure_route[ECRC] { if (t_is_canceled()) { xlog("L_INFO", "Call has been canceled in 'ECRC'."); exit; } xlog("L_INFO", "SIP Response Code: $T_reply_code"); # We should fail over if we received one of these response codes. if (!t_check_status("[45][0-9][0-9]")) { xlog("L_INFO", "Not a failover error."); exit; } # Translate the dialed number into the ECRC DID. dp_translate("1", "$rU/$rU"); # Load the gateways for normal dialing. xlog("L_INFO", "Trying to find LCR route for $rU"); if (! load_gws("1", "$rU")) { xlog("Unable to load routing"); t_reply("503", "Unable to load routing"); exit; } xlog("L_INFO", "Trying gateway '$avp(i:709)'"); if (!next_gw()) { xlog("L_INFO", "No LCR route for $rU"); t_reply("404", "No available gateways"); exit; } $rd=$dd; $rp=$dp; $du=$ru; xlog("L_INFO", "ru: $ru"); xlog("L_INFO", "du: $du"); #at this point $ru and $du contain the correct uri. append_branch(); # Send out the request. xlog("L_INFO", "Now we're sending the request out."); if (!t_relay()) { xlog("L_INFO" "Relay failed!"); t_reply("502", "Bad Gateway"); exit; } } Now I have two SIP messages one containing the correct phone number: INVITE sip:11235550000@xxx.xxx.xxx.xxx SIP/2.0 Record-Route: <sip:xxx.xxx.xxx.xxx;lr=on> Via: SIP/2.0/UDP xxx.xxx.xxx.xxx;branch=z9hG4bK2e2f.4145be65.2 Via: SIP/2.0/UDP xxx.xxx.xxx.xxx:5060;branch=z9hG4bK28aa7440;rport=5060 Max-Forwards: 69 From: "Steven Wheeler" <sip:6124243265@xxx.xxx.xxx.xxx>;tag=as30b3d6f5 To: <sip:11235551234@xxx.xxx.xxx.xxx:5060> ... And one containing the wrong phone number: INVITE sip:11235551234@xxx.xxx.xxx.xxx SIP/2.0 Record-Route: <sip:xxx.xxx.xxx.xxx;lr=on> Via: SIP/2.0/UDP xxx.xxx.xxx.xxx;branch=z9hG4bK2e2f.4145be65.3 Via: SIP/2.0/UDP xxx.xxx.xxx.xxx:5060;branch=z9hG4bK28aa7440;rport=5060 Max-Forwards: 69 From: "Steven Wheeler" <sip:6124243265@xxx.xxx.xxx.xxx>;tag=as30b3d6f5 To: <sip:11235551234@xxx.xxx.xxx.xxx:5060> ... Steven Wheeler swheeler(a)usinternet.com 952-253-3252

3 2

Invitation to connect on LinkedIn
by Andrey Kuprianov via LinkedIn 21 Mar '11

21 Mar '11

LinkedIn ------------Andrey Kuprianov requested to add you as a connection on LinkedIn: ------------------------------------------ Luis, I'd like to add you to my professional network on LinkedIn. - Andrey Accept invitation from Andrey Kuprianov http://www.linkedin.com/e/-y8k3ym-gljdl3wf-1g/XkppUi8mK5TI9VJsZIpnfBovln4Su… View invitation from Andrey Kuprianov http://www.linkedin.com/e/-y8k3ym-gljdl3wf-1g/XkppUi8mK5TI9VJsZIpnfBovln4Su… ------------------------------------------ Why might connecting with Andrey Kuprianov be a good idea? Have a question? Andrey Kuprianov's network will probably have an answer: You can use LinkedIn Answers to distribute your professional questions to Andrey Kuprianov and your extended network. You can get high-quality answers from experienced professionals. http://www.linkedin.com/e/-y8k3ym-gljdl3wf-1g/ash/inv19_ayn/ -- (c) 2011, LinkedIn Corporation

1 0

problem with ser 0.9.6
by Sabatella, Michael 19 Mar '11

19 Mar '11

All, I am a long time lurker but never posted. I am running ser 0.9.6 for many years with no problems. Just recently none of my users can register. Well - they register once then expire out. I noticed that several ser processes are cpu- bound consuming all available cycles. Once they drop register they can never reregister. I restored the ser DB to an older one that was saved when the system was working properly. Any ideas why the ser processes would be CPU bound? Nothing has been changed on the ser proxy in years and the system has been super stable for 2 years. Has anyone seen this behavior in the past? This is from top: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4466 root 25 0 39960 1948 1368 R 35.8 0.0 1:43.97 ser 4477 root 25 0 39960 2028 1448 R 34.5 0.1 0:21.85 ser 4471 root 25 0 39960 2040 1456 R 32.8 0.1 0:47.63 ser 4475 root 25 0 39960 1940 1360 R 32.5 0.0 2:08.90 ser 4470 root 25 0 39960 1916 1336 R 32.2 0.0 1:09.92 ser 4480 root 25 0 39960 1828 1248 R 30.5 0.0 4:45.16 ser Any ideas would be greatly apreciated. Michael See what's next from IPC www.UnigyfromIPC.com<http://www.UnigyfromIPC.com> [cid:unigy-logo-compr64b7.png]<http://www.unigyfromipc.com/> Join the Conversation: LinkedIn<http://www.linkedin.com/groups?mostPopular=&gid=3808474> * Twitter<http://twitter.com/IPC_Systems_Inc> [cid:tree5326.png]Please consider the environment before printing this email. ________________________________ DISCLAIMER: This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unintended recipients are prohibited from taking action on the basis of information in this e-mail.E-mail messages may contain computer viruses or other defects, may not be accurately replicated on other systems, or may be intercepted, deleted or interfered with without the knowledge of the sender or the intended recipient. If you are not comfortable with the risks associated with e-mail messages, you may decide not to use e-mail to communicate with IPC. IPC reserves the right, to the extent and under circumstances permitted by applicable law, to retain, monitor and intercept e-mail messages to and from its systems.

4 7

Re: [SR-Users] $rU isn't used in t_relay() in failure_route
by Steven Wheeler 18 Mar '11

18 Mar '11

Thanks for the quick response, I actually just ended up moving to a newer version of Kamailio (v3.1.2) and that fixed my problem. Steven Wheeler swheeler(a)usinternet.com 952-253-3252 -----Original Message----- From: sr-users-bounces(a)lists.sip-router.org [mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of Klaus Darilion Sent: Friday, March 18, 2011 1:00 PM To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - UsersMailing List Cc: Steven Wheeler Subject: Re: [SR-Users] $rU isn't used in t_relay() in failure_route Am 16.03.2011 21:09, schrieb Steven Wheeler: > $rd=$dd; > $rp=$dp; > $du=$ru; This one I do not understand. Also I do not see the code where you change $dU? Anyway, it seems that 2 branches are added: maybe one by lcr module internally via next_gw and one manually? You can try to change $dU before calling next_gw and omit the append_branch() call. regards klaus _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

1 0

problem with AAAA request when dns query for ipv6 is disabled
by CT Radu 18 Mar '11

18 Mar '11

Did any one had any problem with this? I have a test setup where I have the following directives for dns caching: use_dns_cache=yes #enabling DNS caching dns_cache_del_nonexp=yes # deletes entries if the memory is becoming full dns_cache_flags=0 dns_cache_gc_interval=120 dns_cache_init=on dns_cache_max_ttl=3600 dns_try_ipv6=no # yes if you want the lookup to be for IPv6 also dns_try_naptr=yes despite the fact that I have *dns_try_ipv6=no* kamailio sends a AAAA request to the DNS server. This is an extra request in a case where it seems not to be needed. Also, it seems that a NAPTR request is not sent - I need to investigate more, being just a hunch for now. All the best Radu Costin

1 0

SPCE beyond 50 000 subscribers and 2000 concurrent calls
by Deon Vermeulen 18 Mar '11

18 Mar '11

Hi Guys Can the SPCE platform scale beyond 50 000 subscribers and 2000 concurrent calls when adding more hardware, i.e CPU and RAM? rgds Deon

2 2

problem unreferencing dialog in dialog module
by Anton Roman 18 Mar '11

18 Mar '11

Hi all, we are running Kamailio 3.1.2 in a production environment, using the dialog module, and it crashed two hours ago. Here you have the logs we got (addtional log fragments with the acc records involved in this call are appended at the end of the mail): Mar 2 14:43:05 kamailio2 /usr/local/sbin/kamailio[28927]: CRITICAL: dialog [dlg_hash.c:599]: bogus ref -1 with cnt 1 for dlg 0x7f23f472db30 [2490:1070436595] with clid 'e0a20cb844d211e0acd8001422093865@<CLIENT IP>' and tags '1577886432-3759264324-335599788-1698171170' '' Mar 2 14:43:05 kamailio2 /usr/local/sbin/kamailio[28927]: : <core> [mem/q_malloc.c:446]: BUG: qm_free: freeing already freed pointer, first free: dialog: dlg_cb.c: destroy_dlg_callbacks_list(80) - aborting Mar 2 14:43:05 kamailio2 /usr/local/sbin/kamailio[28896]: ALERT: <core> [main.c:741]: child process 28927 exited by a signal 6 Mar 2 14:43:05 kamailio2 /usr/local/sbin/kamailio[28896]: ALERT: <core> [main.c:744]: core was not generated Mar 2 14:43:05 kamailio2 /usr/local/sbin/kamailio[28896]: INFO: <core> [main.c:756]: INFO: terminating due to SIGCHLD Mar 2 14:43:05 kamailio2 /usr/local/sbin/kamailio[28948]: INFO: <core> [main.c:807]: INFO: signal 15 received Mar 2 14:43:05 kamailio2 /usr/local/sbin/kamailio[28942]: INFO: <core> [main.c:807]: INFO: signal 15 received We get the kamailio code from git last week: sercmd> core.info { version: kamailio 3.1.2 id: 4ace86 compiler: gcc 4.3.2 compiled: 09:12:36 Feb 23 2011 flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES } The problem looks like this other one already fixed: http://lists.sip-router.org/pipermail/sr-users/2009-November/027351.html We set the Kamailio to debug level in case it happens again. On the other side, I need to know why the core is not been generated. I have already checked the points mentioned in http://www.kamailio.org/dokuwiki/doku.php/troubleshooting:corefiles 1. disable_core_dump is not set in the config file. 2. From /etc/default/kamailio: ... DUMP_CORE=yes ... 2. From /etc/init.d/kamailio: ... if test "$DUMP_CORE" = "yes" ; then # set proper ulimit ulimit -c unlimited # directory for the core dump files COREDIR=/home/corefiles [ -d $COREDIR ] || mkdir $COREDIR chmod 777 $COREDIR echo "$COREDIR/core.%e.sig%s.%p" > /proc/sys/kernel/core_pattern fi ... 4. Writting permissions of $COREDIR ls -hall /home ... drwxrwxrwx 2 root root 4.0K 2010-12-21 09:15 corefiles ... What else should I check? Thanks in advance, regards Antón *Acc records related to the dialog whose destruction causes the problem:* Mar 2 14:42:44 kamailio2 /usr/local/sbin/kamailio[28902]: NOTICE: acc [acc.c:275]: ACC: transaction answered: timestamp=1299073364;method=INVITE;from_tag=1577886432-3759264324-335599788-1698171170;to_tag=5FFAEA34-6A;call_id=e0a20cb844d211e0acd8001422093865@<client IP>;code=200;reason=OK;src_user=<caller number>;src_domain=<client IP>;dst_ouser=<called number>;dst_user=<called number>;dst_domain=10.90.1.251;src_ip=<client IP> ... Mar 2 14:42:44 kamailio2 /usr/local/sbin/kamailio[28920]: NOTICE: acc [acc.c:275]: ACC: request acknowledged: timestamp=1299073364;method=ACK;from_tag=1577886432-3759264324-335599788-1698171170;to_tag=5FFAEA34-6A;call_id=e0a20cb844d211e0acd8001422093865@<client IP>;code=200;reason=OK;src_user=<caller number>;src_domain=<client IP>;dst_ouser=<called number>;dst_user=<called number>;dst_domain=10.90.1.251;src_ip=<client IP> ... Mar 2 14:43:00 kamailio2 /usr/local/sbin/kamailio[28903]: ERROR: <script>: ACK WITHOUT MATCHING TRANSACTION in e0a20cb844d211e0acd8001422093865@<client IP> call... ignore and discard. ... Mar 2 14:43:00 kamailio2 /usr/local/sbin/kamailio[28904]: NOTICE: acc [acc.c:275]: ACC: transaction answered: timestamp=1299073380;method=BYE;from_tag=1577886432-3759264324-335599788-1698171170;to_tag=5FFAEA34-6A;call_id=e0a20cb844d211e0acd8001422093865@<client IP>;code=200;reason=OK;src_user=<caller number>;src_domain=<client IP>;dst_ouser=<called number>;dst_user=<called number>;dst_domain=10.90.1.251;src_ip=<client IP>

3 8

NAT Traversal
by Spinov Evgeniy 18 Mar '11

18 Mar '11

May be I miss some important details? No suggestions? Thank you. > Hello, all. > Using nathelper + rtpproxy for subj. Kamailio has public and private > network interfaces. Asterisk is only private. RTP Proxy is working in > bridge mode and relaying traffic from UAC to Asterisks. > Everything is working fine, except one configuration. When the client is > behind router ( a specific one, I do not have an access there to > check ), and this UAC is making a call to other public extension, which > is behind router, then RTP Proxy is relaying traffic to the caller, > using another UDP port, then the packets arrive. > For instance: > UAC 1 -> UAC 2 > PUBLIC_IP:10 > KAMAILIO_IP:5555 > KAMAILIO_IP:5678 > PUBLIC_IP:12 > While for the UAC 2 it looks like: > PUBLIC_IP:20 > KAMAILIO_IP:6767 > KAMAILIO_IP:4564 > PUBLIC_IP:20 > The source and destination UDP ports are the same. As result, I can hear > UAC 1 and he cannot hear me. > In case of we have UAC 3, which is behind other router, call is working > fine with same configuration. > "It's routers fault" you can say, but in the same configuration ( I mean > network, not kamailio ) it worked, but when RTPProxy was not in bridge > mode and Kamailio and Asterisks were in public network. Reinvites are > not allowed in both cases. > The question is, why the source and destination UDP ports are different? > Using STUN in first case, cause without it, private IP written in > contacts and as result, traffic relayed from Kamailio is incorrect, > cause heading to private network which is unreachable. > Any ideas where to dig?

2 5

TM module fr_timer
by Geoffrey Mina 17 Mar '11

17 Mar '11

Hello, I am just curious because I have seen a couple of references to the fr_timer being in SECONDS and some look like they are in MILLISECONDS. In 1.5.X, what is this value? Also - will fr_timer control the retransmission of an INVITE if no 100 Trying is received? Right now it appears my configuration is waiting 500ms to retransmit the INVITE when I don't get a 100 trying. This is what my config looks like right now and this is the behavior I'm seeing. modparam("tm","fr_timer",15) modparam("tm","fr_inv_timer",120) modparam("tm","fr_inv_timer_avp", "$avp(i:704)") INITIAL INVITE [No response in 500ms] RETRANS INVITE [NO response in 1000ms] RETRANS INVITE I'm having a hard time correlating that what I have in my config. Thanks, Geoff

2 1

kamailio with module_s/domain modul
by MÉSZÁROS Mihály 17 Mar '11

17 Mar '11

Hi, Is it possible to use kamailio with module_s/domain.so modul? Could be any known problem occur if i want to use kamailio deb packages with module_s/domain.so? Kamailio has an up2date debian packages unlike ser, but i need modul_s/domain.so modul functionality to manage multiple domain. Thanks, Misi

2 1

RES: RTPPROXY timeout patch.
by Alexandre Abreu 17 Mar '11

17 Mar '11

Hello Carsten. Still no lucky. I just moved the whole rtpproxy/ directory into 3.1 branch and recompiled and then changed my script to use rtpproxy_offer()/rtpproxy_answer(). Look: Mar 15 14:04:38 devel rtpproxy[29111]: INFO:handle_command: new session e2361a59b4588d51, tag ed382a18;1 requested, type strong Mar 15 14:04:38 devel rtpproxy[29111]: INFO:handle_command: new session on a port 44206 created, tag ed382a18;1 Mar 15 14:04:38 devel rtpproxy[29111]: INFO:handle_command: pre-filling caller's address with 192.168.200.114:6380 Mar 15 14:04:39 devel kamailio[29544]: NOTICE: acc [acc.c:275]: ACC: transaction answered: timestamp=1300208679;method=INVITE;from_tag=ed382a18;to_tag=19477c42;call_id =e2361a59b4588d51;code=200;reason=OK; Mar 15 14:04:39 devel rtpproxy[29111]: INFO:handle_command: lookup on ports 44206/41680, session timer restarted Mar 15 14:04:39 devel rtpproxy[29111]: INFO:handle_command: setting custom timeout handler (xmlrpc:http://localhost:8000/RPC2) Mar 15 14:04:39 devel rtpproxy[29111]: INFO:handle_command: pre-filling callee's address with 192.168.200.149:9494 Mar 15 14:04:50 devel rtpproxy[29111]: INFO:process_rtp: session timeout Mar 15 14:04:50 devel rtpproxy[29111]: INFO:remove_session: RTP stats: 963 in from callee, 10 in from caller, 973 relayed, 0 dropped Mar 15 14:04:50 devel rtpproxy[29111]: INFO:remove_session: RTCP stats: 5 in from callee, 1 in from caller, 6 relayed, 0 dropped Mar 15 14:04:50 devel rtpproxy[29111]: INFO:remove_session: session on ports 44206/41680 is cleaned up Started with: rtpproxy -T 10 -F -i -l 192.168.200.90 -s udp:127.0.0.1:7722 -n tcp:192.168.200.90:8000 -d DBUG SIP-ROUTER config: # ----- rtpproxy params ----- modparam("rtpproxy", "rtpproxy_sock", "udp:localhost:7722") modparam("rtpproxy", "rtpproxy_tout", 3) modparam("rtpproxy", "timeout_socket", "xmlrpc:http://localhost:8000/RPC2") # The Port for incoming XML-RPC requests modparam("mi_xmlrpc", "port", 8000) modparam("mi_xmlrpc", "reply_option", 1) modparam("mi_xmlrpc", "buffer_size", 8192) modparam("mi_xmlrpc", "log_file", "/tmp/openser_xmlrpc") The session keeps active after the RTPPROXY proxy timeout. It seems dlg_terminate_dlg isn't being triggered. Am I missing something else beyond moving rtpproxy/ directory? As this thread is a user-question, I am copying SR-USERS mail list. I am also using xmlrpc-c-1.06.41. Thanks, Alexandre. -----Mensagem original----- De: kaiserbock2(a)googlemail.com [mailto:kaiserbock2@googlemail.com] Em nome de Carsten Bock Enviada em: terça-feira, 15 de março de 2011 05:15 Para: Alexandre Abreu Assunto: Re: RTPPROXY timeout patch. Hi Alexandre, sorry, yes, your correct. My changes are not in the 3.1 branch, but only GIT-Master. Only the GIT-Master currently holds the correct patch and config. I will need to backport the changes from the master... (will do so this week). Carsten 2011/3/14 Alexandre Abreu <alexandre.abreu(a)redt.com.br>: > Hello Carsten, > > Let me ask you a question: > > If "First is important to clarify: from version 3.0.0 on, Kamailio and > SER are identical in terms of source code.", then why your changes > does not reflect in kamailio 3.1 from GIT? > I did see the changes by getting the SIP-ROUTER from GIT. Kamailio 3.1 > from GIT does not have your code. > > Thanks. > Alexandre > > -----Mensagem original----- > De: kaiserbock2(a)googlemail.com [mailto:kaiserbock2@googlemail.com] Em > nome de Carsten Bock Enviada em: segunda-feira, 14 de março de 2011 > 05:31 > Para: Alexandre Abreu > Cc: RTPproxy Development > Assunto: Re: RTPPROXY timeout patch. > > Hello, > > i hope, you had a nice weekend... ;-) > Are you sure, you are using the GIT-Version of the > Kamailio/sip-router.org config? > In the GIT version it is now: > > modparam("rtpproxy", "timeout_socket", > "xmlrpc:http://localhost:8000/RPC2") > > http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=blob;f=mod > ules/r > tpproxy/test/kamailio.cfg;h=0d5c73ff2065f33f262981fba2c07e65496e7415;h > b=HEAD > > This should work (as tested by me). > > Carsten > > 2011/3/11 Alexandre Abreu <alexandre.abreu(a)redt.com.br>: >> Hello Carsten, >> >> The patch was applied just fine but I can't get that feature working. >> See >> below: >> >> [root@devel log]# rtpproxy -v >> Basic version: 20040107 >> Extension 20050322: Support for multiple RTP streams and MOH >> Extension >> 20060704: Support for extra parameter in the V command Extension >> 20071116: Support for RTP re-packetization Extension 20071218: >> Support for forking (copying) RTP stream Extension 20080403: Support >> for RTP statistics querying Extension 20081102: Support for setting >> codecs in the update/lookup command Extension 20081224: Support for >> session timeout notifications Extension 20090810: Support for >> automatic bridging Extension 20100819: Support for timeout >> notifications using XML-RPC towards Kamailio/sip-router.org >> >> Using SR 3.1.2, my configuration file was exactly the same as the >> example in test/ subdirectory you commit to rtpproxy module. >> >> # RTP-Proxy >> modparam("rtpproxy", "rtpproxy_sock", "udp:localhost:22222") >> modparam("rtpproxy", "rtpproxy_tout", 3) modparam("rtpproxy", >> "timeout_socket", "http://localhost:8000/RPC2") >> >> # The Port for incoming XML-RPC requests modparam("mi_xmlrpc", >> "port", >> 8000) modparam("mi_xmlrpc", "reply_option", 1) modparam("mi_xmlrpc", >> "buffer_size", 8192) modparam("mi_xmlrpc", "log_file", >> "/tmp/openser_xmlrpc") >> >> Still inside test/ subdir we have the following example: >> >> [root@devel test]# cat exec_rtpproxy.txt ./rtpproxy -T 10 -f -F -i -l >> <your IP> -s udp:*:22222 -d DBUG >> >> You mean that if XML-RPC is used, it has to begin with "xmlrpc:". I >> can't see this string anywhere in these examples. I guess these files >> are not up to date. Am I correct? >> I can see the session timeout in RTPPROXY, but the session does not close. >> If I understand right how this feature works, it should send a >> "dlg_terminate_dlg + call-id" to send the BYE to both sides. >> >> Any tip on what could be wrong? >> >> Thanks, >> Alexandre >> >> -----Mensagem original----- >> De: kaiserbock2(a)googlemail.com [mailto:kaiserbock2@googlemail.com] Em >> nome de Carsten Bock Enviada em: quinta-feira, 10 de fevereiro de >> 2011 >> 20:53 >> Para: Alexandre Abreu >> Cc: RTPproxy Development >> Assunto: Re: RTPPROXY timeout patch. >> >> Hi Alexandre, >> >> i updated the patch in the sip-router-repository (and attached the >> patch to this email). The new patch and the modifications to the >> rtpproxy module need some more testing, i have only done basic > functionality testing so far. >> I have reduced the patch a little, the socket, if the >> XML-RPC-Interface is used, has to begin with "xmlrpc:". This way, the >> protocol of the RTP-Proxy stays intact. >> If you have spare-time, please test it; otherwise, i will do it asap >> (but i am travelling a lot next week). >> >> @Maxim: This new version of the patch is much better, than the old one. >> Maybe you can review this one? Thanks! >> >> Carsten >> >> >> 2011/2/10 Carsten Bock <lists(a)bock.info>: >>> Hi Alexandre, >>> >>> the current GIT-version contains some more modifications regarding >>> timeout sockets. >>> That is the reason why the patch does not work anymore. >>> I will need to review the code and adapt my patch accordingly. >>> I will do so later. >>> >>> Carsten >>> >>> 2011/2/2 Alexandre Abreu <alexandre.abreu(a)redt.com.br>: >>>> Hi Carsten, >>>> >>>> The stable version of RTPProxy is indeed 1.2.1. In this version, >>>> there is no file 'rtpp_notify.c' so I think the patch is really >>>> for git-version. Maybe the original patch was made regarding to an >>>> earlier >> git commit. >>>> >>>> Thanks, >>>> Alexandre >>>> >>>> -----Mensagem original----- >>>> De: kaiserbock2(a)googlemail.com [mailto:kaiserbock2@googlemail.com] >>>> Em nome de Carsten Bock Enviada em: quarta-feira, 2 de fevereiro de >>>> 2011 >>>> 06:02 >>>> Para: Alexandre Abreu >>>> Cc: RTPproxy Development >>>> Assunto: Re: RTPPROXY timeout patch. >>>> >>>> Hi Alexandre, >>>> >>>> the patch was for the stable version of RTP-Proxy (1.2.1?). I will >>>> review the patch for the git-version. >>>> I am a little busy at the moment (business travel), so i can first >>>> do this on friday or next week. >>>> >>>> Kind regards, >>>> Carsten >>>> >>>> P.S.: Please always CC the list. >>>> >>>> 2011/2/1 Alexandre Abreu <alexandre.abreu(a)redt.com.br>: >>>>> Hi Carsten, >>>>> >>>>> >>>>> >>>>> I am testing the new RTPProxy timeout feature in Kamailio (GIT > version). >>>>> >>>>> >>>>> >>>>> Got the rtpproxy from GIT: >>>>> >>>>> git clone git://sippy.git.sourceforge.net/gitroot/sippy/rtpproxy >>>>> >>>>> >>>>> >>>>> I applied the patch: >>>>> >>>>> [root@devel rtpproxy]# patch < rtpproxy.patch >>>>> >>>>> patching file Makefile.am >>>>> >>>>> Hunk #1 FAILED at 4. >>>>> >>>>> 1 out of 1 hunk FAILED -- saving rejects to file Makefile.am.rej >>>>> >>>>> patching file config.h.in >>>>> >>>>> patching file configure.ac >>>>> >>>>> patching file rtpp_command.c >>>>> >>>>> Hunk #1 succeeded at 54 (offset 2 lines). >>>>> >>>>> Hunk #3 succeeded at 272 (offset 2 lines). >>>>> >>>>> Hunk #4 succeeded at 315 with fuzz 2. >>>>> >>>>> Hunk #5 FAILED at 466. >>>>> >>>>> Hunk #6 FAILED at 961. >>>>> >>>>> 2 out of 6 hunks FAILED -- saving rejects to file >>>>> rtpp_command.c.rej >>>>> >>>>> patching file rtpp_notify.c >>>>> >>>>> Hunk #1 FAILED at 38. >>>>> >>>>> Hunk #2 succeeded at 263 (offset 78 lines). >>>>> >>>>> misordered hunks! output would be garbled >>>>> >>>>> Hunk #4 FAILED at 250. >>>>> >>>>> Hunk #5 FAILED at 337. >>>>> >>>>> 3 out of 5 hunks FAILED -- saving rejects to file >>>>> rtpp_notify.c.rej >>>>> >>>>> patching file rtpp_notify.h >>>>> >>>>> Hunk #1 succeeded at 39 with fuzz 2 (offset 8 lines). >>>>> >>>>> patching file rtpp_session.c >>>>> >>>>> patching file rtpp_session.h >>>>> >>>>> >>>>> >>>>> As you see, not so clean but the files were patched. >>>>> >>>>> >>>>> >>>>> On CentOS 5, I cant find the LIBXMLRPC through YUM/RPM, so I >>>>> compiled xmlrpc-c-1.06.41.tgz by hand: >>>>> >>>>> >>>>> >>>>> ./configure prefix=/usr && make && make install >>>>> >>>>> AND ./configure && make && make install >>>>> >>>>> With that, the headers are both on /usr/lib/include and >>>>> /usr/local/lib/include (I did that just to be sure that the config >>>>> wasnt looking at the wrong place). >>>>> >>>>> >>>>> >>>>> xmlrpc_abyss.h >>>>> >>>>> xmlrpc_cgi.h >>>>> >>>>> XmlRpcCpp.h >>>>> >>>>> xmlrpc_server.h >>>>> >>>>> xmlrpc_client.h >>>>> >>>>> xmlrpc.h >>>>> >>>>> xmlrpc_server_w32httpsys.h >>>>> >>>>> >>>>> >>>>> The configure script from patched RTPPROXY doesnt _try_ to find >>>>> the LIBXMLRPC (theres no reference in config.log) and therefore >>>>> my rtpproxy doesnt have the support for the timeout notification. >>>>> >>>>> >>>>> >>>>> Any comment on what could be wrong? >>>>> >>>>> >>>>> >>>>> Alexandre >>>> >>>> >>>> >>>> -- >>>> Carsten Bock >>>> Schomburgstr. 80 >>>> 22767 Hamburg >>>> Germany >>>> >>>> Mobile +49 179 2021244 >>>> Home +49 40 34927217 >>>> Büro (Verl) +49 5246 801427 >>>> Fax +49 40 34927218 >>>> mailto:carsten@bock.info >>>> >>>> >>> >>> >>> >>> -- >>> Carsten Bock >>> Schomburgstr. 80 >>> 22767 Hamburg >>> Germany >>> >>> Mobile +49 179 2021244 >>> Home +49 40 34927217 >>> Büro (Verl) +49 5246 801427 >>> Fax +49 40 34927218 >>> mailto:carsten@bock.info >>> >> >> >> >> -- >> Carsten Bock >> Schomburgstr. 80 >> 22767 Hamburg >> Germany >> >> Mobile +49 179 2021244 >> Home +49 40 34927217 >> Büro (Verl) +49 5246 801427 >> Fax +49 40 34927218 >> mailto:carsten@bock.info >> >> > > > > -- > Carsten Bock > http://www.ng-voice.com > mailto:carsten@ng-voice.com > > -- Carsten Bock http://www.ng-voice.com mailto:carsten@ng-voice.com

2 13

Release for SPCE version 2.2
by Deon Vermeulen 17 Mar '11

17 Mar '11

Hi Guys When can we expect the release of spce version 2.2? Kind Regards Deon Vermeulen

1 0

Kamailio - Asterisk CDR
by Lucas Alvarez 17 Mar '11

17 Mar '11

Hi, I have an integration kamailio-asterisk. I have many calls that don't pass through asterisk, kamailio route that calls to other media gateways. I would like to log those calls in asterisk CDR, is that possible? Could someone give me any direction? Thanks in advance. Lucas

4 3

Problem on multiple interfaces and conversion between UDP and TCP
by David 16 Mar '11

16 Mar '11

Hello, I have a Kamailio 3.0 server with two interfaces. 192.168.x.x and a public interface. I send PUBLISH out on the private interface to my presence server. Everything else happens on the public address. I did not use the "listen=" option in the config, so Kamailio was automatically detecting my interfaces to bind to. Last night I had a provider sending packets in on TCP and Kamailio was sending out on UDP. Unfortunately, it kept using the private interface despite that the IP was unreachable on this interface. It looks like Kamailio uses the first interface it finds when converting between TCP and UDP, and I believe that on the server, the private interface was being listed first. I finally added listen= in kamailio with all 4 interfaces ( tcp/udp public and tcp/udp private ). I listed the public UDP interface first, restarted and the packets started going out on the public interface. Is this a feature or a bug ? How does Kamailio decide which interface to use ? What if I sent a packet to an IP that is only reachable on one interface? At the very least, I think that a note about this difficulty should be included in the default config so that future users don't have the same issue I did. Thanks, David

2 1

getting fragmented packet when adding record-route header
by Asgaroth 16 Mar '11

16 Mar '11

Hi All, I have a scenario where I have 2 asterisk media servers that, when calling a registered sip account, will forward off the invite to a location server, who looks up the contact information, then forwards the invite off to the proxy that the user registered against (done via the path module). This all appears to work perfectly until the us hangs up the call. The BYE message does not make it all the way back to the originating asterisk media server, it makes it back to the location server that looked up the registration information. To overcome this issue, I add a "Record-Route" header specifying the address of the asterisk media server that the request originated from. However, when I add the custom header, the Invite shows up as fragmented packet my wire-shark trace at the end-user's soft-phone. The call sets up properly and when I hang up it looks like the BYE message makes it all the way back to the media server, but when it is relayed on the the caller, the sip proxy then fails the call with a message too big. If I remove the line that adds the record-route header, then all looks fine, except that I am unable to tear down calls from sip end-points. The specific line I'm using to add the header is as follows: insert_hf("Record-Route: <sip:$si:$sp;lr=on>\r\n","Record-Route"); I do remove this from the route header on in-dialog replies as loose-route does not remove the header on the original location server as it does not see the route header as local, so I manually remove it. Has anyone come across this particular issue? I'm using Kamailio 3.1.2. Am I going about this is the wrong way? I've been reading the module docs for registrar/usrloc/rr/path/textops to see if there is something I've missed but cannot see it. Any tips/suggestions would be greatly appreciated. Thanks

3 7

ACK not sent and rr-enforced
by Dominguez Jover, Ricardo 16 Mar '11

16 Mar '11

Hi everybody. I am using Kamailio 3.1 and RTP proxy for internet calls. I'm using external test accounts to check if the calls are established and the media flow is ok. When I use a sip2sip.info or VoIP Talk accounts, then all is working fine between my internal and these external accounts. But when I use a iptel.org account and this account calls to an internal account (registered with kamailio), then callee sends the 200 OK to the SIP proxy and the SIP proxy to iptel. IPtel.org proxy sends the ACK to my proxy with this lines at the end of the packet: P-hint: rr-enforced\r\n P-hint: rr-enforced\r\n And my SIP proxy never resends the ACK to the callee, so the callee resends OK 200 periodically and after 32 seconds sends a BYE message and the call is finished. I've been reading posts about missing ACKs but I can't find the answer to my problem, that it seems like "t_check_trans" doesn´t recognize the ACK as related to a transaction. But this is only with IPTEL accounts, my proxy SIP is working with other SIP providers, so I don't know if forcing relay of every ACK packet is a good idea. Any help would be appreciated. Thanks, Ricardo

4 10

Installation Problem: : /usr/local/sbin/kamailio: not found
by Derrick Ding 16 Mar '11

16 Mar '11

Hi, All Yesterday I install Kamailio(3.1.x) by myself under a new Ubuntu server 10.04 environment. I got it from http://www.kamailio.org/pub/kamailio/3.1.2/bin/ kamailio-3.1.2_linux_i386.tar.gz <http://www.kamailio.org/pub/kamailio/3.1.2/bin/kamailio-3.1.2_linux_i38 6.tar.gz> I put all stuff under corresponding directory: /usr/local/sbin with bin file /usr/local/etc/kamailio with .cfg file /usr/local/lib/kamailio with lib file Based on http://www.kamailio.org/dokuwiki/doku.php/install:kamailio-3.1.x-from-gi t I create /etc/init.d/kamailio PATH=/sbin:/bin:/usr/sbin:/usr/bin DAEMON=/usr/local/sbin/kamailio NAME=kamailio DESC=kamailio HOMEDIR=/var/run/kamailio PIDFILE=$HOMEDIR/$NAME.pid DEFAULTS=/etc/default/kamailio RUN_KAMAILIO=no Also I create /etc/default/ kamailio I find a problem after when I run /etc/init.d/kamailio start, it says: root@aastra:/etc/init.d# /etc/init.d/kamailio start Not starting kamailio: invalid configuration file! -e /etc/init.d/kamailio: 168: /usr/local/sbin/kamailio: not found But the file is there: root@aastra:/etc/init.d# ls -l /usr/local/sbin/kamailio -rwxr-xr-x 1 root root 4103257 2010-07-01 12:16 /usr/local/sbin/kamailio root@aastra:/etc/init.d# /usr/local/sbin/kamailio bash: /usr/local/sbin/kamailio: No such file or directory I wonder if this /usr/local/sbin/kamailio is not for Ubuntu server 10.04 and cannot be run Thanks for help Derrick

2 3

major bug in auth module?
by Juha Heinanen 16 Mar '11

16 Mar '11

one sip ua sent this kind of authorization header: Authorization: Digest username="foo",realm="bar",uri="xxx",response="e439fa7438452da7d50690f2268be16f",nonce="4d8060d2000041b2430e64fe7ec681d8fb5709e9c72b8a01",qop=auth,cnonce="0004ccb0",nc=000060a2. and sr auth module didn't like it but emitted error message FIXME:check_nonce: bad nc value. i went and checked the code and found this: if (nc_enabled && (pf & NF_VALID_NC_ID) && auth->digest.nc.s && auth->digest.nc.len){ if (str2int(&auth->digest.nc, &nc)!=0){ /* error, bad nc */ ERR("FIXME:check_nonce: bad nc value %.*s\n", auth->digest.nc.len, auth->digest.nc.s); return 5; /* invalid nc */ } i.e., looks like it is using str2int to convert to nc value to int. the problem is that str2int only handles decimal strings, whereas nc value is a hex string. am i dreaming or what? -- juha

1 1

LCR Routes and memory allocations
by Graham Wooden 15 Mar '11

15 Mar '11

Hi there, I have now approximately 400,000 routes defined in my LCR table and I would like to make sure that I have enough memory allocated for it. I read somewhere (a non official Kamailio site) about PKG_MEM_POOL_SIZE and SHM_MEM_SIZE needing to be altered to handle the increased routes. System is dedicated for the Kamailio 1.5.5 install and has 4GB of RAM. Thoughts to what I need to change these values (or anything else) to accommodate? Thanks, -graham

5 6

Error: compile kamailio with STUN support
by Derrick Ding 15 Mar '11

15 Mar '11

Hi, All I met same problem when compile kamailio with STUN support. http://www.voipuser.org/forum_topic_18741.html /usr/include/bits/string3.h:83: warning: memset used with constant zero length parameter; this could be due to transposed parameters ser_stun.o: In function `add_fingerprint': /root/kamailio-3.0.1/ser_stun.c:890: undefined reference to `SHA1' ser_stun.o: In function `validate_fingerprint': /root/kamailio-3.0.1/ser_stun.c:973: undefined reference to `SHA1' collect2: ld returned 1 exit status make: *** [kamailio] Error 1 I search online that need link libssl -lssl But I don't know where to add this compile flag. The Makefile of this project is too complicated for me to understand. Any one can tell me how to I can fix this? By the way, I have install libssl. It's /usr/lib/libssl.so.0.9.8 Sincerely, Derrick

2 1

Q.850 Reason in CANCEL on Kamailio 3.0
by Jeremy McNamara 15 Mar '11

15 Mar '11

I am attempting to add a Reason header with Q.850 result codes. Unfortunately, this does not work: if (is_method("CANCEL")) { append_hf("Reason: Q.850; cause=16\r\n"); if (t_check_trans()) { t_relay(); } exit; } If I have to use 3.1.x, does it support sending Q.850 codes? Jeremy McNamara

2 4

Kamailio setup
by roman＠dmytriv.com 15 Mar '11

15 Mar '11

Hello everyone!!! What location I use for chrooted directory? Thanks in advance Roman

2 1

Re: [SR-Users] Call subscriber online
by Daniel-Constantin Mierla 15 Mar '11

15 Mar '11

Hello, shouldn't the call go to location service before relaying to subscriber B? Is B at a fix address an port and that is local host port 5060? Are you doing all in your computer for testing purposes, because otherwise an application bound to localhost (like could be the softphone B) cannot really communicate with the inter/intra-network? Cheers, Daniel On 3/11/11 4:50 PM, Stefano Larosa wrote: > > Hi, > > I'm new on Kamailio 3.0 > > This is the scenario I would like to build: > > 1 Subscriber A -> 2 kamailio -> 3 asterisk -> 4 Kamailio -> 5 > Subscriber B > > Everything is working fine until the last step > > This is the code that manage the call from asterisk to kamailio > > /if(is_method("INVITE") && (src_ip==80.169.xx.xx) )/ > > / {/ > > / route(TOPROXYUSER);/ > > / }/ > > And this is the code that should end the call the the subscriber > > route[TOPROXYUSER] { > > xlog("L_NOTICE", "$mi route[$rm][0] $fu > -> $ru START PROCESSING MESSAGE\n"); > > rewritehostport("127.0.0.1:5060"); > > if (is_method("BYE|CANCEL")) { > > route(FAIL_ONE); > > } else if (is_method("INVITE")){ > > route(RELAY); > > }; > > exit; > > } > > Thank you, > > Stivu. > > > _______________________________________________ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users(a)lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- Daniel-Constantin Mierla http://www.asipto.com

2 1

Registrar module creates an extra branch
by Efelin Novak 15 Mar '11

15 Mar '11

Hi Folks, I have a problem with registrar module (I suppose). When A calls to B, is some specific situation, B receives two INVITEs. This mostly (not only) happens when one account is registered on two or more UAs. In this situation extra INVITE is sent only to the one that is second in the list (kamctl ul show ACCOUNT). kamctl ul show Alice: Contact:: <sip:orlvuzyd@192.168.28.72:52129 >;q=0;expires=1916;flags=0x0;cflags=0x40;socket=<udp:8.8.8.8:5060 >;methods=0xFFFFFFFF;received=<sip:8.8.8.8:52129>;user_agent=<Blink 0.2.5 (Linux)> Contact:: <sip:Alice@192.168.28.51:5060 >;q=;expires=3061;flags=0x0;cflags=0x40;socket=<udp:8.8.8.8:5060 >;methods=0x129F;received=<sip:8.8.8.8:5060 >;user_agent=<Linksys/PAP2T-3.1.15(LS)> My situation. 1. Alice calls to BOB. 2. kamailio looks up in location table for BOBs registrations 3. in DB there are two rows (two devices(linksys PAP2T and Blink(blink is second one))) 4. kamailio send 3 INVITES ( linksys, blink and blink). Every INVITE has different via.branch (Via: SIP/2.0/UDP 8.8.8.8;branch=z9hG4bKe2d7.009b1df2.1) (Via: SIP/2.0/UDP 8.8.8.8;branch=z9hG4bKe2d7.009b1df2.2) (Via: SIP/2.0/UDP 8.8.8.8;branch=z9hG4bKe2d7.009b1df2.3) All my registrar parameters are set to default. I have no idea whether this is a bug or my missconfiguration. Thanks for replies. Kind regards, Efelin Novak

2 2

usuarios para kamailio y asterisk
by M. ASUNCION MERINO RODRIGUEZ 14 Mar '11

14 Mar '11

Hola en la actualidad estoy montando un servidor kamailio que trabaja con un servidor asterisk. Entiendo que lo mejor seria que tanto kamailio como asterisk trabajaran con los mismos usuarios, por eso el servidor kamailio autentica los usuarios contra un servidor radius. Este servidor radius, acceder a un directorio ldap, para validar a los usuarios cuyo usuario es el login de correo y la contraseña correspondiente. Mi pregunta es, como puedo manejar usuarios como "login" si en asterisk existen usuarios creados como números de telefono? debería hacer que los usuarios de radius fueran numeros de telefono? Cualquier ayuda es bienvenida Gracias

1 0

Paging from asterisk to accounts with Multiple Registrations...
by Derrick Bradbury 14 Mar '11

14 Mar '11

Hi all... interesting problem... I am using kamailio as the registration server for a cluster of asterisk servers. I am allowing multiple registrations on the same account to allow for parallel forking on a normal call... The problem is set paging... when I send the page to the account that has multiple registrations, the parallel fork works properly and the first phone to respond gets "control" of the call. Unfortunately there is an auto answer field in the invite. So simple case: one account, two phones.. invite gets sent to both phones, both phones answer... BUT one phone grabs "control" of the call, and the other phone no longer receives any more commands... so it never hangs up as it doesn't receive a "BYE". Is there any way to turn off the parallel fork behavior, and keep sending all packets to both (or more) phones? Any thoughts are appreciated! Thanks, Derrick

2 1

Re: [SR-Users] decimal fraction problem
by Daniel-Constantin Mierla 14 Mar '11

14 Mar '11

Hello, cc-ing to the mailing list is very important because even it is an email to show the previous answer was good, that will help other people with similar problem that search on web and read the mailing list archive to know the proposed solution worked and they can use it without asking again on mailing list if it was ok or not. Thanks, Daniel On 3/14/11 12:07 PM, 侯旭光 wrote: > got it > > thanks > > cheers > > 在 2011年3月14日下午5:22，Daniel-Constantin Mierla <miconda(a)gmail.com> 写道： >> Hello, >> >> are you using kamailio 3.1.x? If not, you have to upgrade, the >> $branch(...) variable was updated to be writable starting with this version. >> >> I played last week with it in a need of combining serial forking with >> parallel forking and all is ok with assigning values to $branch(...). >> >> Cheers, >> Daniel >> >> On 3/14/11 5:25 AM, 侯旭光 wrote: >>> sorry to bother again >>> >>> >>> $(branch(q)[-1]) = $var(q); >>> >>> this script line doesn't work and the pv $branch() aren't >>> writable,just readable . index -1 is not accessable either. >>> >>> if append_branch() function doesn't take the q value parameter,the >>> $branch(q) just return NULL (which I think is the default value >>> Q_UNSPECFIED=-1) >>> >>> I find a function set_ruri_q() in dset.c but I don't know how to call >>> it in the configure file. >>> >>> >>> 2011/2/23 Daniel-Constantin Mierla <miconda(a)gmail.com>: >>>> Hello, >>>> >>>> On 2/21/11 10:28 AM, 侯旭光 wrote: >>>> >>>> Hello >>>> I need to add q value while using function append_branch(),but the function >>>> only takes decimal fraction as the parameter. >>>> What if I want to use pv to add q value? >>>> The $var and $avp just have string and integer type. >>>> Thanks a lot! >>>> >>>> do: >>>> >>>> km_append_branch("$var(branchuri)"); >>>> $(branch(q)[-1]) = $var(q); >>>> >>>> $var(q) has to hold an integer value that represents the decimal fraction >>>> value multiplied with 100 (so if q should be 0.5, then $var(q) = 50). >>>> >>>> Cheers, >>>> Daniel >>>> >>>> -- >>>> Daniel-Constantin Mierla >>>> http://www.asipto.com >>> _______________________________________________ >>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >>> sr-users(a)lists.sip-router.org >>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >> -- >> Daniel-Constantin Mierla >> http://www.asipto.com >> >> -- Daniel-Constantin Mierla http://www.asipto.com

1 0

change in list setup - default is now reply to list
by Henning Westerholt 14 Mar '11

14 Mar '11

Hello, for your information - i just did a small change in the mailling list configuration for sr-dev and sr-users, now all replies goes per default to the list instead of the sender. This should help to keep the discussion on the list, especially if new people join. :-) In the past a lot of "Please always include the list in your reply" reminders were necessary.. If you choose "reply to all" then the mail still goes to the list and the sender, so no change in this case. Regards, Henning

2 1

Siremis - Auto update dialplan on save?
by Russell Feeser 14 Mar '11

14 Mar '11

To Siremis Admin, I'm a bit of a php rookie, and even more of a noob with openbiz cubi, but I've burnt a day and a half trying to implement a new button on the SER Menu > Server Services > Dialplan List page, and curious if you could give some words of advice concerning my plight. Ideally, I would like dialplan to auto update the Kamailio mySQL database with the dp_reload feature; I am simply sick of bouncing Kamailio with a "kamctl restart" from the command line each time I implement a change to the dialplan in Siremis. I have successfully enabled this feature on the drop-down menu in SER Menu > Command Services > MI Commands, however, I don't want to have to navigate to the MI Commands page each time I wish to refresh dialplan. In siremisMICommands.xml, I was able to activate dp_reload with the following code: (taken from siremisMICommands.xml) <?xml version="1.0" standalone="no"?> <PluginService Name="siremisMICommands" Package="asipto" Class="siremisMICommands"> <MIConfig name="MIConfig" type="udp" mode="rich"> <Local name="local" address="127.0.0.1" port="8044" timeout="3.0"/> <Remote name="remote" address="127.0.0.1" port="8033"/> <MICommands> <cmd name="ps" title="List Processes" command="ps"/> <cmd name="uptime" title="Show Uptime" command="uptime"/> <cmd name="getstatsall" title="Get All Statistics" command="get_statistics all"/> <cmd name="which" title="Get All MI Commands" command="which"/> <cmd name="dp_reload" title="Reload Dailplan" command="dp_reload"/> <------ Code I added, WORKS! </MICommands> </MIConfig> </PluginService> Here's where I'm stuck: I can't seem to get a new button to implement dp_reload in the DialplanListForm.xml. I'm not sure if I need to write a function to call dp_reload, or if I can simply activate dp_reload from the DialplanListForm.xml. The code I have written creates a button on the SER Menu > Server Services > Dialplan List page, but thats as far as I've gotten. My code currently looks like this: (taken from DialplanListForm.xml) <Element Name="btn_refresh" Class="Button" Text="Activate" CssClass="button_gray_m" Description="Refresh dialplan in Kamailio without restarting Kamailio"> <EventHandler Name="dp_reload" Event="onclick" EventLogMsg="" Function="" ContextMenu="Activate"/> </Element> Anything you can say would be most helpful, as this is a feature I'm sure many using Siremis would appreciate having. Best, -- R. Z. Feeser 717.460.8095 www.RZFeeser.com www.NaturaGardens.com

2 1

pseudo variables available in on_reply route
by Asgaroth 14 Mar '11

14 Mar '11

Hi All, I have a requirement to perform some processing based on the source and destination addresses on a message in on_reply route. I can get source ip address using $si pseudo variable, but I cant seem to access the destination ($dd). Is there any way I can access destination ip/domain of message in on_reply route? Thanks for any tips.

2 1

Register a CISCO IP phone
by Pang, Gary (Liguang) 14 Mar '11

14 Mar '11

Dear Sir, I have a difficulty to register a CISCO SPA 303 IP phone. I can register a Soft phone to the SER server by setting the Hold IP address, Proxy, account number.. But it is not working with the CISCO phone. Can you advice? Thanks, Gary

3 2

decimal fraction problem
by 侯旭光 14 Mar '11

14 Mar '11

Hello I need to add q value while using function append_branch(),but the function only takes decimal fraction as the parameter. What if I want to use pv to add q value? The $var and $avp just have string and integer type. Thanks a lot!

2 3

OPENSER MIB
by Stefan Tiedje 14 Mar '11

14 Mar '11

Hi, In the Kamailio OPENSER-MIB there is the counter "openserTotalNumFailedDialogSetups". This is a Counter32. The description is: "The total number of calls that failed with an error. The following codes define a failed call:" Question: * I'm looking for the corresponding counter to "openserTotalNumFailedDialogSetups" who counts successful Dialog setups of Counter32 type. Does it exist? * If not, does it exist a work around? * Where in the code can the new suggested counter be added? * Something else???? Suggestion for the new counter is a name like: "openserTotalNumSucceededDialogSetups". It has a counter32. Description: "The total number of calls that succeeded" I know that there are the counters openserCurNumDialogs, openserCurNumDialogsInProgress and openserCurNumDialogsInSetup but these are of Gauge type who only reflects the current situation. These Gauge counters can't be used together with a Counter32 counter. That don't mix. The calculation done for the counter "openserCurNumDialogsInProgress" should be used where every new dialog setup is added to the new suggested counter. A counter of 32 should cover a great deal of connections. These counters are usually read, if used, every 15 minutes or 1 hour. Rationale: The reason for the new counter is that a calculation between succeeded and failed dialog setups can be done and be used for SLA agreements. Without this, its hard to make any customer versus provider agreements. /Stefan PS. Ask if anything is unclear and I need an answer rapidly.

2 1

acc failed_transaction_flag and t_newtran()
by Juha Heinanen 12 Mar '11

12 Mar '11

in order to get invite requests accounted, it seems that accounting flags need to be set before t_newtran() is called. is there any way to unset the accounting flags after calling t_newtran()? for example, i would not like to account invites that result to 407 proxy authentication required. -- juha

2 4

pseudo variables available in on_reply route
by Asgaroth 11 Mar '11

11 Mar '11

Hi All, I have a requirement to perform some processing based on the source and destination addresses on a message in on_reply route. I can get source ip address using $si pseudo variable, but I cant seem to access the destination ($dd). Is there any way I can access destination ip/domain of message in on_reply route? Thanks for any tips.

5 8

Call subscriber online
by Stefano Larosa 11 Mar '11

11 Mar '11

Hi, I'm new on Kamailio 3.0 This is the scenario I would like to build: 1 Subscriber A -> 2 kamailio -> 3 asterisk -> 4 Kamailio -> 5 Subscriber B Everything is working fine until the last step This is the code that manage the call from asterisk to kamailio if(is_method("INVITE") && (src_ip==80.169.xx.xx) ) { route(TOPROXYUSER); } And this is the code that should end the call the the subscriber route[TOPROXYUSER] { xlog("L_NOTICE", "$mi route[$rm][0] $fu -> $ru START PROCESSING MESSAGE\n"); rewritehostport("127.0.0.1:5060"); if (is_method("BYE|CANCEL")) { route(FAIL_ONE); } else if (is_method("INVITE")){ route(RELAY); }; exit; } Thank you, Stivu.

1 0

kamailio setup
by roman＠dmytriv.com 10 Mar '11

10 Mar '11

Hello there! I'm in the process of setting my first kamailio server and run into dead end. I was following your instructions very closely at http://www.kamailio.org/dokuwiki/doku.php/install:kamailio-3.1.x-from-git I'm using Centos 5.5 i386. Everything vent pretty much fine until step 7 were I had to create MySQL database. When I run /usr/local/kamailio-3.1/etc/kamailio/kamctlrc it gives me "Permission denied" error. I was able to access kamctlrc with a text editor and uncommented DBENGINE=MYSQL. Now when I run /usr/local/kamailio-3.1/sbin/kamdbctl create I have ERROR 2002. Please take a look at the attachment. Please help. Roman

4 3

Question about LCR
by Geoffrey Mina 10 Mar '11

10 Mar '11

Hello, I have a question about LCR which I have been unable to solve. I have 4 upstream carrier gateways owned by 2 carriers. Each carrier provides a primary and secondary gateway for load balancing purposes. On a 5XX error I am trying to send the same call to the other carrier. If both carriers reject the call with 5XX, I allow the response to go downstream to my asterisk server. The issue I am running into is that in a scenario where both my carriers respond with a 5XX, I end up presenting the same call to all 4 gateways. I would like to present the call to one gateway on each carrier and not try the same carriers second gateway for the same call. Here is what is happening now: ASTERISK --> INVITE --> KAMAILIO INVITE --> CARRIER A/GATEWAY 1 <-- 5XX Error INVITE --> CARRIER A/GATEWAY 2 <-- 5XX Error INVITE --> CARRIER B/GATEWAY 1 <-- 5XX Error INVITE --> CARRIER B/GATEWAY 2 <-- 5XX Error KAMAILIO --> 5XX Error --> ASTERISK OR any combination of the above... i.e. ASTERISK --> INVITE --> KAMAILIO INVITE --> CARRIER A/GATEWAY 1 <-- 5XX Error INVITE --> CARRIER B/GATEWAY 2 <-- 5XX Error INVITE --> CARRIER B/GATEWAY 1 <-- 5XX Error INVITE --> CARRIER A/GATEWAY 2 <-- 5XX Error KAMAILIO --> 5XX Error --> ASTERISK What I want to happen is: ASTERISK --> INVITE --> KAMAILIO INVITE --> CARRIER A/GATEWAY 1 or 2 <-- 5XX Error INVITE --> CARRIER B/GATEWAY 1 or 2 <-- 5XX Error KAMAILIO --> 5XX Error --> ASTERISK I tried dealing with the issue using some flags on the gateway, but i couldn't get the logic to work properly. Here is the path I was heading down, but my plan fell apart after some testing. CARRIER A has a gateway flag of "1" CARRIER B has a gateway flag of "2" failure_route[1]{ $var(gw_flag) = $avp(i:712); while(next_gw()){ if($var(gw_flag) != $avp(i:712)){ xlog("L_INFO","Found an LCR destination which is different than current, routing. ($ci)"); t_on_reply("1"); t_on_failure("1"); t_relay(); exit; }else{ xlog("L_INFO","The next destination in LCR has the same AVP flag, skipping. ($ci)"); } } # let the reply go upstram - it is the default action xlog("L_ERR", "No Next Gateway - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); exit; } Any help would be greatly appreciated. Thanks, Geoff

4 6

kamailio setup
by roman＠dmytriv.com 09 Mar '11

09 Mar '11

Hello there! I'm in the process of setting my first kamailio server and run into dead end. I was following your instructions very closely at http://www.kamailio.org/dokuwiki/doku.php/install:kamailio-3.1.x-from-git I'm using Centos 5.5 i386. Everything vent pretty much fine until step 7 were I had to create MySQL database. When I run /usr/local/kamailio-3.1/etc/kamailio/kamctlrc it gives me "Permission denied" error. I was able to access kamctlrc with a text editor and uncommented DBENGINE=MYSQL. Now when I run /usr/local/kamailio-3.1/sbin/kamdbctl create I have ERROR 2002. Please take a look at the attachment. Please help. Roman

1 0

Does Kamailio support RFC5626 as Edge Proxy(or outbound proxy)
by Derrick Ding 09 Mar '11

09 Mar '11

Dear All, I wonder if Kamailio supports RFC5626 as edge proxy or outbound proxy. That is, Edge Proxy adds a Path header with a flow token and includes the "ob" parameter when Processing Register Requests. Eg: Path: <sip:VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@ep1.example.com;lr;ob> If does, how can I config it in kamailio.cfg. At present, Kamailio can only forward register msg to sip server and reply 200 OK to SIP UA with "require: outbound" when register accepted. No "Path" and "ob" added in the msg forwarded to SIP server. You answer is appreciated!! Sincerely, Derrick

3 3

#!define and #!subst problem
by Klaus Darilion 09 Mar '11

09 Mar '11

Hi! I tried #!subst "/IPADDRESS_VIRTUAL/83.136.32.161/" listen=udp:IPADDRESS_VIRTUAL:5060 and #!define IPADDRESS_VIRTUAL 83.136.32.161 listen=udp:IPADDRESS_VIRTUAL:5060 Both do not work - am I doing something wrong or is this a known limitation with "listen" statements? Thanks Klaus

2 2

dispatcher confusion
by Klaus Darilion 07 Mar '11

07 Mar '11

Hi! Every time I use the dispatcher(k) module I am confused again. Sometimes it seems that "probing" is a dedicated state, sometimes it seems that "probing" is done also in "active" state, but never in "inactive" state. IMO "probing" should only be a flag which indicates if OPTIONS should sent or not. If probing is successful, then the state should be "active". If probing is unsuccessful, then the state should be "inactive". Current behavior is very strange (ds_probing_mode(0)): --> startup state: A --> no probing kamctl fifo ds_set_state i 1 sip:.... --> state: I --> no probing kamctl fifo ds_set_state a 1 sip:.... --> state: A --> no probing calling 3 times ds_mark_dst("p") --> state: P --> probing (and dst is still loaded as last value into the dst_avp, why?) kamctl fifo ds_set_state i 1 sip:.... --> state: I --> still probing kamctl fifo ds_set_state a 1 sip:.... --> state: P (???) --> probing Thus, "ds_set_state a ..." does not set active, but probing if it was probing before. Strange. And as "inactive" does not stop probing when dst was in probing mode, the destination becomes automatically "active" if the probing succeeds. And why is a destination in probing mode loaded into the dst_avp? Very weird. Is there a reason for this behavior? Thanks Klaus

3 4

Kamailio 3.0.4: dispatcher module request
by Klaus Feichtinger 07 Mar '11

07 Mar '11

Hello list, I have a question to the dispatcher module in Kamailio version 3.0.4. In my integration I use this module for distributing calls to a set of gateways (with the round robin algorithm). Sometimes a gateway does not react or send back a negative response. In that case I use the function 'ds_mark_dst("p")' in the failure_route and mark the current destination with the flag 'probing'. I have set the threshhold value for probing mode to '10'. This means that a gateway is effectively set to probing mode only when it was marked with the flag 'probing' for 10 times. However, sometimes a gateway is sending back a negative response for e.g. 5 times and is afterwards working fine - without any problems. A few hours later (e.g.) it is sending a negative reply again for one time. This means: the counter for the probing_flags is increasing every time when the function ds_mark_dst("p") is executed (in case that the process was not restarted in the meantime!). So the problem is, that the counter is reaching the threshhold value at any time and at that moment the gateway is set to probing mode. Even if the gateway has sent a negative reply for only one time (at that moment) - but according the history the proging_flag was set several times. What I miss in this module is a function to _reset_ that flag counter from a REPLY_ROUTE. Note: I have to reset the counter, because the gateway does not yet SIP OPTIONS requests and therefore it is set to 'probing' all time until it is manually set back to active via MI command or after a process restart. According the README file (and practical experience) the function ds_mark_dst() is executable only within the failure_route. However, when I want to set the flag ("a") for the current destination I will do it within a reply_route, but not in the failure_route (because I have received a positive response and not a negative one). From my point of view it does not make sense setting the 'active' flag for a destination from within a FAILURE route. Does anybody have an idea, how the 'flag-counter' could be reset (from within the script)? I do not want to use a MI command..... configuration excerpt: [...] modparam("dispatcher", "db_url", "mysql://openser:openserrw@localhost/openser") modparam("dispatcher", "table_name", "dispatcher") modparam("dispatcher", "dst_avp", "$avp(AVP_DST)") modparam("dispatcher", "grp_avp", "$avp(AVP_GRP)") modparam("dispatcher", "cnt_avp", "$avp(AVP_CNT)") modparam("dispatcher", "ds_ping_from", "sip:proxy@192.168.37.87") modparam("dispatcher", "ds_probing_mode", 0) modparam("dispatcher", "ds_probing_threshhold", 10) modparam("dispatcher", "ds_ping_interval", 30) modparam("dispatcher", "flags", 2) modparam("dispatcher", "force_dst", 1) [...] if (!ds_select_dst("1", "4")) { sl_send_reply("404", "No destination (disp)"); exit; } t_on_failure("failureroute"); t_on_reply("replyroute"); [...] failure_route[failureroute] { [...] if (t_check_status("[45][08]0") || (t_branch_timeout() && !t_branch_replied())) { ds_mark_dst("p"); if (!ds_next_dst()) { t_reply("404", "No destination (disp)"); exit; } t_on_failure("failureroute"); t_on_reply("replyroute"); } [...] } onreply_route [replyroute] { if (t_check_status("180|200") { # nice to have...... # ds_mark_dst("a"); } } Thanks in advance! regards, Klaus

2 4

Siremis Installation - Hangs at Database Configuration Page
by Tim Nelson 07 Mar '11

07 Mar '11

Greetings- I'm attempting an installation of Siremis on a CentOS 5.5 64-bit system running Kamailio 3.1.0. Following the instructions on the wiki [1], I find that I cannot pass step 3 for the database configuration. I've triple checked all of my details are correct and verified the permissions are set appropriately on the Siremis source dir. Also, I've successfully run 'make apache-config' and 'make prepare'. After clicking 'next', I simply get the 'Loading... please wait awhile' graphic. On three different fresh installs, I've waited for 3 hours each. By now, I have to assume it shouldn't be taking this long and there is an error somewhere. The Apache logs don't indicate anything of interest other than a missing favicon. Do you have any ideas? Thank you! --Tim [1] http://kb.asipto.com/siremis:install20:main

1 0

Limit call duration
by Hans Goossens 07 Mar '11

07 Mar '11

Hi, I'm wondering if there is a easy way to limit the call duration in Kamailio ? I would like to automaticaly end the call when the max. duration (for example 12 hours) is reached. In the feature overview of Kamailio 1.5 I found: "option to send BYE when dialog expires" but i'm can't figure out how to get this working (if it's still implemented at all in the current version). Thanks in advance, Kind regards Hans

2 2

about syn_branch
by Juha Heinanen 07 Mar '11

07 Mar '11

we noticed that if sr 3.1 config does not contain syn_branch=0 then acks to 200 oks that are t_relayed by sr, contain branch=0 param in topmost via. in kamailio 1.5, via branch param has proper value even when tm param syn_branch is not set. a couple of questions: 1) according to core cookbook, syn_branch core param only affects stateless forwarding. in my config, all acks are t_relayed, i.e., syn_branch param should not have any effect, but is does. how is that possible? is there a bug in core cookbook? 2) should t_relaying of acks to 200 oks use proper (i.e.. non 0) via branch param even when syn_branch is not set to any value in config? if not why? if yes, will branch=0 be used only when ack to 200 ok does not match any invite transaction? -- juha

2 3

How to access additional xavp's
by Alex Hermann 07 Mar '11

07 Mar '11

Hello, I'm currently toying with xavp's and have some trouble accessing the values. I want to have access to the xavp that isn't the last added one. From the wiki page on http://sip-router.org/wiki/devel/xavp I got the impression that indices are supported, but that doesn't seem to work. In the following fragment i want access to the values 1A & 1B, how to do that? $xavp(test=>a) = "1A"; $xavp(test[0]=>b) = "1B"; $xavp(test=>a) = "2A"; $xavp(test[0]=>b) = "2B"; xlog("$xavp(test[0]=>a)"); xlog("$xavp(test[0]=>b)"); xlog("$xavp(test[1]=>a)"); xlog("$xavp(test[1]=>b)"); pv_xavp_print(); Which gives the following result: Dec 21 14:30:35 veyron wsproxy1[10398]: ERROR: <script>: 2A Dec 21 14:30:35 veyron wsproxy1[10398]: ERROR: <script>: 2B Dec 21 14:30:35 veyron wsproxy1[10398]: ERROR: <script>: <null> Dec 21 14:30:35 veyron wsproxy1[10398]: ERROR: <script>: <null> Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:470]: +++++ XAVP list: 0xb3a38770 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:473]: *** XAVP name: test Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:474]: XAVP id: 2063405720 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:475]: XAVP value type: 6 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:496]: XAVP value: <xavp:0xb3a387c4> Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:470]: +++++ XAVP list: 0xb3a387c4 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:473]: *** XAVP name: b Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:474]: XAVP id: 110 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:475]: XAVP value type: 2 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:484]: XAVP value: 2B Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:473]: *** XAVP name: a Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:474]: XAVP id: 109 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:475]: XAVP value type: 2 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:484]: XAVP value: 2A Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:505]: ----- XAVP list Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:473]: *** XAVP name: test Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:474]: XAVP id: 2063405720 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:475]: XAVP value type: 6 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:496]: XAVP value: <xavp:0xb3a386c8> Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:470]: +++++ XAVP list: 0xb3a386c8 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:473]: *** XAVP name: b Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:474]: XAVP id: 110 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:475]: XAVP value type: 2 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:484]: XAVP value: 1B Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:473]: *** XAVP name: a Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:474]: XAVP id: 109 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:475]: XAVP value type: 2 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:484]: XAVP value: 1A Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:505]: ----- XAVP list Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:505]: ----- XAVP list -- Greetings, Alex Hermann

2 4

Balancing Asterisk
by Andy Lippitt 07 Mar '11

07 Mar '11

Hello all, I've read as many of the asterisk balancing threads as I can find. Either my situation is unusual or I simply haven't understood anything I've read. In short, I'm building an web/phone mashup which uses Asterisk's AGI to get its work done. My only users are on the PSTN connected to Asterisk through a SIP trunk provider. So presently, in and out through the same trunk, apps live on the single Asterisk box. My goal is scaling and failover. I don't have any need for cross talk or transfers between the asterisk instances, and the algo's in dispatcher seem fine. It seems to me that I should be setting the sip-router up a replacement for the existing peer in Asterisk. What leaves me scratching my head is how I then register the sip-router with the upstream provider. Alternatively, if I use the sip-router as an outboundproxy from asterisk (which seems like it's going to take some hacking to make this work in 1.4), doesn't this now mean I have multiple UAC's trying to register for the same name? Can someone set me on the right track? Thanks, Andy Lippitt

2 1

Newly acquired SIP fails authorization from softphone
by Larry Baumbach 06 Mar '11

06 Mar '11

I am a newbie to the world of VIOP. I am attempting to set up an ATA with SIP. I created a SIP at account iptel.com and received an email confirmation stating "We are reserving the following SIP address for you: sip:larry.baumbach@iptel.org". I tried to testing this address in Xlite but got messages saying: "Account failed to enable. Account Iptel could not be enabled. Verify your user ID, password and authorization name. When I set up the SIP account in Xlite I used: UserID: larry.baumbach(a)iptel.org ( I also tried "larry.baumbach" & "sip:larry.baumbach@iptel.org") Domain: sip.iptel.org Password: my password Authorization name: (I left blank as I did not receive any) I can log into SERweb with the same UserID and Password and access my account. What am I doing wrong? Or is there some kind of wait time before my SIP address is activated? I have spent too much time trying to get this to work on my own. Thanks very much for any help you can provide. -- Larry Baumbach 920.358.8695 larry.baumbach(a)gmail.com

2 1

Re: [SR-Users] [sr-dev] planning release of v3.1.2
by Bernhard Suttner 06 Mar '11

06 Mar '11

Hi, whats about: http://sip-router.org/tracker/index.php?do=details&task_id=108 I think that some users are trying to register to an asterisk system. Or does somebody have a solution for that? A new release would be nice!!! Thanks in advance. Best regards, Bernhard ----- Original Message ----- From: Daniel-Constantin Mierla [mailto:miconda@gmail.com] To: kamailio [mailto:sr-users@lists.sip-router.org], sr-dev [mailto:sr-dev@lists.sip-router.org] Sent: Fri, 28 Jan 2011 20:15:50 +0100 Subject: [sr-dev] planning release of v3.1.2 > Hello, > > I think it is time to release v3.1.2, first date that comes in my mind > is next Thursday if everyone feels it is enough time to take care of > backporting any fix he/she did and it is not yet there. That will > provide us a fresh release for the FOSDEM event. If not, then maybe the > other week, Tuesday, so the participants at the Kamailio Devel training > in Barcelona can practice on it. > > Soon after we should plan also a release for previous stable, branch 3.0. > > Anyone having other options? > > Thanks, > Daniel > > -- > Daniel-Constantin Mierla > http://www.asipto.com > > > _______________________________________________ > sr-dev mailing list > sr-dev(a)lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev >

2 1

Kamailio auth_radius: duplicate User-Name attribute
by Kosilov Fedor 06 Mar '11

06 Mar '11

Hello List! I'm trying to set up authorization with our billing proprietary radius server, using Freeradius as a proxy. Currently I'm experiencing the following problem: The Access-Request packet, sent by Kamailio, contains two User-Name attribute records Here is a log from the Freeradius server: rad_recv: Access-Request packet from host 127.0.0.1 port 59294, id=112, length=298 User-Name = "2219001(a)example.com" Digest-Attributes = 0x0a0932323139303031 Digest-Attributes = 0x01106c696e6b2d726567696f6e2e7275 Digest-Attributes = 0x022254584452634531773045524b7368796f30684a70544f4f6a69424d386b32534a Digest-Attributes = 0x04147369703a6c696e6b2d726567696f6e2e7275 Digest-Attributes = 0x030a5245474953544552 Digest-Attributes = 0x050661757468 Digest-Attributes = 0x090a3030303030303031 Digest-Attributes = 0x080c32383034636535373032 Digest-Response = "e79b47955c02401fe52d05f7956609aa" Service-Type = Sip-Session Sip-Uri-User = "2219001" * User-Name = "call-id=domcmqmnychbwlp@koffe-work"* NAS-Identifier = "kamserv.example.com" NAS-Port = 5060 NAS-IP-Address = 127.0.0.1 # Executing section authorize from file /etc/freeradius/sites-enabled/default +- entering group authorize {...} ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop [digest] Checking for correctly formatted Digest-Attributes [digest] Digest-Attributes look OK. Converting them to something more usful. Digest-User-Name = "2219001" Digest-Realm = "example.com" Digest-Nonce = "TXDRcE1w0ERKshyo0hJpTOOjiBM8k2SJ" Digest-URI = "sip:example.com" Digest-Method = "REGISTER" Digest-QOP = "auth" Digest-Nonce-Count = "00000001" Digest-CNonce = "2804ce5702" [digest] Adding Auth-Type = DIGEST ++[digest] returns ok [suffix] Looking up realm "example.com" for User-Name = "2219001(a)example.com " [suffix] Found realm "example.com" [suffix] Adding Realm = "example.com" [suffix] Proxying request from user 2219001 to realm example.com [suffix] Preparing to proxy authentication request to realm "example.com" ++[suffix] returns updated [eap] No EAP-Message, not doing EAP ++[eap] returns noop ++[files] returns noop ++[expiration] returns noop ++[logintime] returns noop ++[pap] returns noop Sending Access-Request of id 250 to 127.0.0.1 port 1822 User-Name = "2219001(a)example.com" Digest-Attributes = 0x0a0932323139303031 Digest-Attributes = 0x01106c696e6b2d726567696f6e2e7275 Digest-Attributes = 0x022254584452634531773045524b7368796f30684a70544f4f6a69424d386b32534a Digest-Attributes = 0x04147369703a6c696e6b2d726567696f6e2e7275 Digest-Attributes = 0x030a5245474953544552 Digest-Attributes = 0x050661757468 Digest-Attributes = 0x090a3030303030303031 Digest-Attributes = 0x080c32383034636535373032 Digest-Response = "e79b47955c02401fe52d05f7956609aa" Service-Type = Sip-Session Sip-Uri-User = "2219001" * User-Name = "call-id=domcmqmnychbwlp@koffe-work"* NAS-Identifier = "kamserv.example.com" NAS-Port = 5060 NAS-IP-Address = 127.0.0.1 Proxy-State = 0x313132 Proxying request 1 to home server 127.0.0.1 port 1822 As I understand, this second User-Name attribute has to be a call-id attribute.

3 5

Calls are killed during kamailio restart
by Efelin Novak 04 Mar '11

04 Mar '11

Hi, I'd like to ask whether my situation is normal. During kamailio restart calls are dropped from mediaproxy. Those two programs are connected using kamailio.sock. Why RTP strem is dropped when SIP proxy is restarted? I would expect just undelivered BYE or something. Thanks for answer, Efelin

4 3

WARNING: <core> [db_id.c:281]: identical DB URLs, but different DB connection pid [30123/30107]
by Klaus Darilion 04 Mar '11

04 Mar '11

Any idea what does it mean? Where does it come from? Do I have to change my config? How? WARNING: <core> [db_id.c:281]: identical DB URLs, but different DB connection pid [30123/30107] Thanks Klaus

5 7

re-SUBSCRIBE and Record-Route
by marius zbihlei 04 Mar '11

04 Mar '11

Hello list, An UAC sends a resubscribe in the form SUBSCRIBE sip:Alice@example.com SIP/2.0 Route: <sip:sip.example.com;lr=on> Route:<sip:sip.next-hop.example.com;lr=on> .... The request has a to tag, from tag... Basic resubscribe(R-URI is the same as original SUBSCRIBE) The proxy that handles it is a Kamailio (1.5 but this refers to 3.1 as well). The problem is that loose_route() treats this request as coming from a strict routing router, not from the UAC, so it applies the strict-to-loose rules and rewrites the request as: SUBSCRIBE sip:sip.next-hop.example.com;lr=on SIP/2.0 Route: <sip:sip.example.com;lr=on> .... The segment that handles this is pretty standard: if (loose_route()) { # sequential request withing a dialog should take the path # determined by record-routing if(has_totag()) { forward(); exit; } It sees that message has Route set, it finds the to tag (so the routes were not a preset), and then , the important thing, sees that the domain from the RURI matches itself (kamailio has aliases configured for example.com), thus considering the request as coming from a strict router. Then it takes the bottom Route header and overwrites the RURI. What is the best way to ensure that loose routing is applied to the resubscribe as described above? Cheers, Marius

3 5

Re: [SR-Users] set_dlg_profile() in failure_route
by Timo Reimann 04 Mar '11

04 Mar '11

Hey 侯旭光, please keep SR-Users in CC so others can share in some assistance and benefit from a solution. On 04.03.2011 08:29, 侯旭光 wrote: > I did trace the dialog in the initial REQUEST > > my script: > ... > modparam("dialog","dlg_flag","4") > ... > route{ > > if (is_method("INVITE")){ > dlg_setflag("2"); > dlg_manage(); > ... > if(avp_db_load("$ruri/username","$avp(s:busyforward)")) > { > setflag(26); > t_on_failure(FAIL_ONE); > } > ... > } > failure_route[FAIL_ONE]{ > ... > if(isflagset(26)&&t_check_status("486")) > { > $ru=$avp(s:busyforward); > append_branch(); > dlg_setflag("2"); > avp_delete("$avp(s:busyforward)"); > resetflag("26"); > lookup("location"); > route(RELAY); > } > ... > } > route[RELAY]{ > if(!t_relay()){ > sl_reply_error(); > } > } > #----------------------------------------------------------------------# > > Is anything wrong? You set flag 2 but showed flag 4 to be modparam'ed to the dialog flag. Is that intentional? Anyways, since you are doing dlg_manage() in the INVITE transaction, you should still be fine. Just for the sake of debugging, can you set flag 4 in your 'is_method("INVITE")' block and see if it makes a difference? I have no in-depth experience with on demand dialog tracking as we use the dialog flag exclusively. By the way, I see no calls to set_dlg_profile() in your route logic. Is this really an excerpt of the configuration you are having trouble with? Cheers, --Timo > > 2011/3/3 Timo Reimann <timo.reimann(a)1und1.de>: >> Hi, >> >> >> On 03.03.2011 14:47, 侯旭光 wrote: >>> set_dlg_profile() function carshed in failure_route when I need do the >>> call-forwarding. >>> >>> When in busy-call-forward or no-answer-forward mode ,it'll run into >>> the failure_route.But at the time , the route_type of the dialog is >>> FAILURE_ROUTE and the get_current_dialog() return NULL, >>> >>> then the set_dlg_profile() function won't work. >>> >>> How can I set dialog profile in the busy or no-answer call-forwarding ? >>> >>> CRITIAL dialog [dlg_profile.c]: BUG - dialog not found in non > REQUEST route >>> ERROR dialog [dialog.c] : failed to set profile >> >> I think you did not track the dialog in the first place, i.e., when the >> initial request associated to the dialog you seek to profile was > processed. >> >> Are you using dlg_flag, and if so, have you enabled it in REQUEST_ROUTE? >> If you want to track dialogs on demand instead, try calling dlg_manage() >> prior to calling set_dlg_profile(). I'm not sure if this is the most >> elegant approach for your use case but it might at least work. >> >> >> Cheers, >> >> --Timo

1 1

set_dlg_profile() in failure_route
by 侯旭光 04 Mar '11

04 Mar '11

Hello set_dlg_profile() function carshed in failure_route when I need do the call-forwarding. When in busy-call-forward or no-answer-forward mode ,it'll run into the failure_route.But at the time , the route_type of the dialog is FAILURE_ROUTE and the get_current_dialog() return NULL, then the set_dlg_profile() function won't work. How can I set dialog profile in the busy or no-answer call-forwarding ? LOG file CRITIAL dialog [dlg_profile.c]: BUG - dialog not found in non REQUEST route ERROR dialog [dialog.c] : failed to set profile thanks

2 2

Re: [SR-Users] About RPM of Kamailio
by Ovidiu Sas 02 Mar '11

02 Mar '11

Please post your questions to the mailing list. If you want to build an rpm, the location of the spec file is available in the source tree: ./pkg/kamailio/rpm/kamailio.spec.CenOS If you prefer a link: http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=blob;f=pkg/kama… Regards, Ovidiu Sas On Wed, Mar 2, 2011 at 5:56 AM, Suresh Bhandari <bring2sb(a)yahoo.com> wrote: > Hello Ovidiu, > > I searched through the kamailio.org/pub but can't find what you said. > > Can you verify the exact location of package that you've downloaded. > > Thanks. > Suresh > >

1 0

how to combine alias_db_lookup() with lookup()
by x-kamailio＠sidell.org 02 Mar '11

02 Mar '11

I'm trying to use the db_alias module as a way to define "generic" addresses that map to a set of actual phones. For example, I'd like the alias "home(a)foo.bar" to map to "kitchen(a)foo.bar" and "office(a)foo.bar", so that both phones ring when a call comes in to "home". I have set the append_branches param to 1: modparam("alias_db", "append_branches", 1) I also modified the dbaliases database table so that key "alias_idx" isn't unique, thereby allow me to add multiple rows for the same alias. The relevant script section is taken verbatim from 3.1 kamailio.cfg: # USER location service route[LOCATION] { #!ifdef WITH_ALIASDB # search in DB-based aliases alias_db_lookup("dbaliases"); #!endif if (!lookup("location")) { switch ($rc) { case -1: case -3: xlog( "L_WARN", "XXX $ru $fu\n"); t_newtran(); t_reply("404", "Not Found"); exit; case -2: sl_send_reply("405", "Method Not Allowed"); exit; } } # when routing via usrloc, log the missed calls also if (is_method("INVITE")) { setflag(FLT_ACCMISSED); } } When I place a call to an alias, the kamailio debug log shows that alias_db_lookup() is correctly setting the ruri to the first entry found in the table, and using append_branch() to add the others. But only the first matching phone gets an INVITE, not the others. I suspect that the lookup() call is blowing away the branches set up by alias_db_lookup() and replacing them with the single phone that matches the ruri for the first alias entry. Is there a way to get alias_db_lookup() and lookup() to play together, so that the first function can set up a list of branches, and the second function can resolve all of the branches to the actual device locations? -- Mark Sidell Partner Forte, Inc. 919-942-7068 fax 919-969-2844 www.forteinc.com

2 1

Radius authentication
by Pablo Ros 02 Mar '11

02 Mar '11

I am trying to authenticate through radius (info in LDAP database). I am using kamailio 3.1 First of all I would like to clear up an issue: As shown the way to do the authentication is done with: *Code:* if (! radius_www_authorize("uu.net")) { www_challenge("uu.net", "0"); return; } Ok, when I installed openser I did it with kamailio "flavour" so it was using the auth_radius module belonging to it. Does anyone know which would be the correct way to do the challenge to the user cause is was not working at all. The radius client does not even send it. I got stuck some time till I just decided to load the module from ser modules folder and then freeradius server started to get correctly my requests. Actually I can even see it authenticates them correctly. However Openser/Kamailio doesn't seem to see the same and it doesn't saves location. *Code:* route[AUTH] { #!ifdef WITH_AUTH # Primeramente comprobamos si pertenece a nuestro dominio; si no ya no hace falta comprobar credenciales. if (uri==myself) { if (is_method("REGISTER")) { xlog("L_NOTICE","KAM-INFO: r[AUTH] - REGISTER - User info: ($fu):($si)>\n"); if (!radius_www_authorize("i2cat.net")){ route(RADIUS); #www_challenge("i2cat.net","0"); exit; } } if ($au!=$tU) { sl_send_reply("403","Forbidden auth ID"); exit; } } else { #!ifdef WITH_IPAUTH if(allow_source_address()) { # source IP allowed return; } #!endif # authenticate if from local subscriber if (from_uri==myself) { if (!proxy_authorize("$fd", "subscriber")) { proxy_challenge("$fd", "0"); exit; } if (is_method("PUBLISH")) { if ($au!=$tU) { sl_send_reply("403","Forbidden auth ID"); exit; } } else { if ($au!=$fU) { sl_send_reply("403","Forbidden auth ID"); exit; } } consume_credentials(); # caller authenticated } else { # caller is not local subscriber, then check if it calls # a local destination, otherwise deny, not an open relay here if (!uri==myself) { sl_send_reply("403","Not relaying"); exit; } } } #!endif return; } Before doing the challenge then it just goes throught: *Code:* route[RADIUS] { sl_send_reply("100", "Trying"); append_to_reply("Expires: 600\r\n"); append_to_reply("Min-Expires: 240\r\n"); xlog("L_NOTICE","KAM-INFO: RADIUS AUTHENTICATION - AUTHORIZING USER $fU - <$fu>:<$si>\n"); xlog("L_NOTICE","KAM-INFO: CHALLENGING. - RETCODE-> $rc \n"); www_challenge("i2cat.net", "0"); switch($rc){ case -5: xlog("L_INFO", "-> 500: internal server error"); sl_send_reply("500", "Internal Server Error"); case -4: xlog("L_INFO", "-> 404: credentials not found"); sl_send_reply("404", "Credentials Not Found"); case -3: xlog("L_INFO", "-> 400: bad request - stale nonce"); sl_send_reply("400", "Bad Request"); case -2: xlog("L_INFO", "-> 401: invalid password"); sl_send_reply("401", "Invalid Password"); case -1: xlog("L_INFO", "-> 401: invalid user"); sl_send_reply("401", "Invalid User"); default: xlog("L_INFO", "-> 401: unauthorized"); sl_send_reply("401", "Unauthorized"); } } Buuuuuuuuuuuuut... I got that in the debug of Kamailio: *Code:* 4(31099) DEBUG: auth [api.c:95]: auth: digest-algo: MD5 parsed value: 1 4(31099) DEBUG: auth_radius [sterman.c:271]: radius_authorize_sterman(): Success 4(31099) WARNING: auth_radius [authorize.c:89]: RADIUS server did not send SER-UID attribute in digest authentication reply 4(31099) DEBUG: auth [challenge.c:102]: build_challenge_hf: realm=' i2cat.net' 4(31099) DEBUG: auth [challenge.c:113]: build_challenge_hf: qop='auth' 4(31099) DEBUG: auth [challenge.c:236]: auth: 'WWW-Authenticate: Digest realm="i2cat.net", nonce="TWZJLk1mSAKFVzL0b+dVPzkuyyAnZHQs", qop="auth" I guess it has something to do with this SER-UID attribute and thus something about the dictonary? It is weird seeing that the radius server says 'ok' but then openser is not authenticating it. I need some clues! Thank you!. -- Pablo Ros

2 1

rtpproxy and connection information field
by Dominguez Jover, Ricardo 01 Mar '11

01 Mar '11

Hi all, I'm using rtpproxy 1.2.1 and kamailio. RTPproxy is working fine in almost every case. However I have a problem with some call. When softphone A using sip2sip.info account calls softphone B using my Kamailio server account, the Kamilio receives SIP packets from IP1 (81.23.228.129). The invite packet has IP2 (81.23.228.150) in the conecction information field (c=IN IP4 81.23.228.150): INVITE sip:12345@xxxxxxxx.xxx;transport=udp SIP/2.0 Record-Route: <sip:81.23.228.129;lr;ftag=d9e99adf;did=e81.3538c317> Via: SIP/2.0/UDP 81.23.228.129;branch=z9hG4bKd14b.12802794.0 Via: SIP/2.0/UDP 192.168.xx.xx:7964;received=88.xx.xx.xx;branch=z9hG4bK-d8754z-8ba1b4b47e37bb89-1---d8754z-;rport=7964 Max-Forwards: 69 Contact: <sip:54321@88.xxx.xxx.xxx:7964;transport=udp> To: "2205"<sip:12345@xxxxxxxx.xxx> From: "R sip2sip"<sip:54321@sip2sip.info>;tag=d9e99adf Call-ID: OGE5MTFiMzljZjE0NTYxN2M0N2VkZjgzNDRhMzE2ZTA. CSeq: 2 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Content-Type: application/sdp Supported: replaces User-Agent:xxxxxxxxxxxxxxxxxxxxxxxxx Content-Length: 279 v=0 o=- 12943454020854250 1 IN IP4 192.168.xxx.xx s=xxxxxxxxxxxxxxxxxxxx c=IN IP4 81.23.228.150 t=0 0 m=audio 52854 RTP/AVP 107 0 8 18 101 a=rtpmap:107 BV32/16000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=yes a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv Then Kamilio translates "c=" IP address to my RTPproxy IPaddress and sends the INVITE to softphone B. After the OK softphone B sends RTP packets to the RTPproxy as specified in the "c=" field, however the RTPproxy sends RTP packets to IP1 instead of send packets to IP2. How can I tell the RTPproxy to send packets to IP2 (the one in the c= field?) Thanks, Ricardo Dominguez

1 1

Segfault in Kamailio 1-3-4 to 1.5.5
by Andrew O. Zhukov 01 Mar '11

01 Mar '11

In continue of letters: Kamailio 1.5.5 No TLS Segmentation Fault After upgrade from openser 1.3.4 to kamailio 1.5.5 the same crash set Can someone from developers provide me commercial support to fix this bug in malloc module. If so, contact me directly.

6 12

modulo operator
by Klaus Darilion 01 Mar '11

01 Mar '11

Hi! Using kamailio 3.1.1, I failed to use '%' as described in the core cookbook. Using 'mod' instead seems to work. regards Klaus

2 3

Kamailio Installation
by Suresh Bhandari 01 Mar '11

01 Mar '11

Hello Community, I am new to Kamailio, and this list as well. I am trying to install Kamailio 3.1.2, but I am getting too many errors. I have fixed some but still not getting the way. I am using Red Hat Enterprise Linux (RHEL) 5, and /usr/local directory. When I ran the following command: make group_include="standard standard-dep mysql" include_modules="carrierroute peering" install it prompted not found error for the file docbookx.dtd, I found it (modules/auth/auth.xml, and modules_s/acc_syslog/acc_syslog.xml) and fixed it as it was errorenous URL location. For reference earlier it was http://www.oasis-open.org/docbookid/id/g/4.5/docbookx.dtd, which I changed to http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd. Now when I run the previous command again, I am getting the follwing errors: *nsgmls:<URL>http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd:116:17:E: "X20AC" is not a function name* If I ignore this, and continue, I am not able to find the "sip-router" service in /etc/init.d. The entire errors is attached here. Please help me solve the issue. TIA Suresh

2 1

no private memory left after mi mt_reload command
by Javier Gallart 28 Feb '11

28 Feb '11

Hi all we are running kamailio 3.1.1. Basically for every call it has to query a mtree that is reloaded every 15 minutes. The mtree table is about 4M records and is stored in a Pgostgres database. For the reload we use the command mi mt_reload embedded in a xmlrpc request. The code for this is: route[XMLRPC]{ if (method == "POST" || method == "GET") { if (search("^User-Agent:")) { xlog("xmlrpc request\n"); set_reply_close(); set_reply_no_connect(); # optional dispatch_rpc(); } exit; } } This server has been running with no issued for some weeks now, but at some point during the weekend the mi command started to fail. This is what the logs show: ERROR: <core> [db_res.c:181]: no private memory left ERROR: db_postgres [km_res.c:225]: could not allocate rows ERROR: db_postgres [km_dbase.c:280]: failed to convert rows ERROR: mtree [mtree_mod.c:627]: Error while fetching result ERROR: db_postgres [km_dbase.c:318]: invalid parameter value ERROR: mtree [mtree_mod.c:738]: cannot re-load info from database I've restarted kamailio and now it's working fine. Should we increase the private memory? On the other hand, we'd like to detect this failure condition on the script and act accordingly (for instance sending an email with an alarm message), is there anyway to do this? Thanks in advance Regards Javier

2 7

Re: [SR-Users] Can only tranfer (refer) a call one time
by Youngjin Park 28 Feb '11

28 Feb '11

> Hi, > > Can you tell me what advantage on INVITE has against REFER? > > REFER is a kind of blind transfer and INVITE in sipXbridge is 3PCC? > > Thanks in advance. > > Youngjin > > > On Sun, Feb 27, 2011 at 6:40 AM, Grzegorz Stanislawski < > stangrze(a)netitel.pl> wrote: > >> Hi. >> We have proverb for this, i don't know english version but it goes like >> this: >> "When it isn't known what it's all about, it's about money" >> >> Your ITSP had troubles with proper handling second transfer for billing >> purposes so decided to disable it. >> Proxy doesnt participate in call transfer, but ITSP it must charge users >> properly: Alice should pay just for call to Bob, Bob for "his" call to >> Charlie and so on. >> If You are using sipX You should use sipXbridge, it replaces REFER with >> INVITE and bridges calls. >> >> Grzegorz Stanislawski >> >> >> >> W dniu 2011-02-25 11:40, niklas rehnberg pisze: >> >>> Hi, >>> Thank for the quick response. >>> The issue occur only when the Alice is a PSTN client. >>> My ITSP says that they only supporting one call transfer (very strange). >>> They can not explain why etc... >>> PSTN client: Alice >>> MGW/MGC(ITSP): Cisco/SER >>> Our sip server: SIPX >>> >>> BR Niklas >>> 2011/2/25 Iñaki Baz Castillo <ibc(a)aliax.net <mailto:ibc@aliax.net>> >>> >>> 2011/2/25 niklas rehnberg <niklas.rehnberg(a)gmail.com >>> <mailto:niklas.rehnberg@gmail.com>>: >>> > Hi, >>> > Have following issue: >>> > >>> > Alice calling Bob. >>> > Bob make call transfer to Charlie (works fine) >>> > Charlie transfer Alice to David. (the call break) >>> > >>> > Why is not possible to transfer the call more than one time? >>> > Is it any parameters? >>> > >>> > My ITSP use SER together with Cisco MGW. >>> >>> Niklas, nothing in SIP protocol neither in SER/Kamailio makes your >>> scenario to fail. It must be a problem in your custom setup. Try >>> identifying the problem capturing SIP traces. >>> Also take into account that a proxy doesn't participate at all in the >>> process of a "call transfer". It's just a transparent mechanism for a >>> proxy. >>> >>> -- >>> Iñaki Baz Castillo >>> <ibc(a)aliax.net <mailto:ibc@aliax.net>> >>> >>> >>> >>> >>> _______________________________________________ >>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >>> sr-users(a)lists.sip-router.org >>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >>> >> >> >> _______________________________________________ >> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >> sr-users(a)lists.sip-router.org >> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >> > >

2 1

Re: [SR-Users] kamctl db exec
by Henning Westerholt 28 Feb '11

28 Feb '11

On Saturday 26 February 2011, 侯旭光 wrote: > But I need to use the feature, is it aviliable or not? Hi 侯旭光, ok.. Have you tried if its work with an simple example? kamctl exec "show databases" Cheers, Henning

1 0

UC Expo 2011, London, next week
by Daniel-Constantin Mierla 28 Feb '11

28 Feb '11

Hello, I will be visiting the first day of UC Expo in London (http://www.ucexpo.co.uk/), Tuesday, March 8. If you are going to be there and want to meet for a chat about Kamailio & VoIP, drop me an email. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

1 0

Re: [SR-Users] Unable to start Siremis
by jack＠4voice.net 28 Feb '11

28 Feb '11

1 0

Re: [SR-Users] Unable to start Siremis
by hb 28 Feb '11

28 Feb '11

Hi jack： I got the same problem with you. I know little about apache and HTML, would you tell me how to configuration apache specific. Thanks a lot. haibo huang

1 0

how to route to new URI on failure
by x-kamailio＠sidell.org 27 Feb '11

27 Feb '11

I'm trying to route failed calls to a voicemail URI. The failure route couldn't be simpler: failure_route[FAIL_ONE] { if (t_is_canceled()) { exit; } if( t_check_status("486|408") { append_branch( "sip:foo@2.2.2.2"); t_relay(); } } But, it doesn't work. For example, let's say the initial INVITE resolves to a local device "me(a)1.1.1.1". This works fine, and the phone rings. After a timeout, the failure_route executes. The branch "foo(a)2.2.2.2" gets appended, and kamailio sends a new INVITE, but instead of determining the correct proxy for the new address, it sends the INVITE, with the new URI, to the device that original received the INVITE, "me(a)1.1.1.1". Obviously, this doesn't work. I've been able to force kamailio to route the call correctly by modifying failure_route[ to use t_relay_to_udp() as follows: failure_route[FAIL_ONE] { if (t_is_canceled()) { exit; } if( t_check_status("486|408") { append_branch( "sip:foo@2.2.2.2"); t_relay_to_udp( "2.2.2.2", "5060"); } } But, it seems like kamailio should figure what where to send the new INVITE itself. What am I doing wrong? -- Mark Sidell Partner Forte, Inc. 919-942-7068 fax 919-969-2844 www.forteinc.com

2 2

Can only tranfer (refer) a call one time
by niklas rehnberg 27 Feb '11

27 Feb '11

Hi, Have following issue: Alice calling Bob. Bob make call transfer to Charlie (works fine) Charlie transfer Alice to David. (the call break) Why is not possible to transfer the call more than one time? Is it any parameters? My ITSP use SER together with Cisco MGW. BR Niklas

4 4

Lcr Command Disabled
by Amit Nepal 25 Feb '11

25 Feb '11

Lcr is working fine but Why would i get LCR commands disabled ? kamctl lcr reload ERROR: command disabled-- Thank You Amit Nepal Systems Administrator Phoenix Internet Phone: 602-385-0731 602-234-0917#112 http://www.phoenixinternet.net

3 8

Rtpproxy newbie question
by Marc 25 Feb '11

25 Feb '11

Hi, I installed a kamailio from the debian repository, i use the default configuration. The only enable the tcp and tls transport modes, and configured mysql login. Everyting seems to be working fine. I would need now to configure rtprpoxy, but i just cant make it work. My goal is to force rtpproxy for all calls. Any help is highly appreciated!! Thank you Marc Rtpproxy is installed and seems to be running: This is my rtpproxy configuration: ------------ # Defaults for rtpproxy # The control socket. #CONTROL_SOCK="unix:/var/run/rtpproxy/rtpproxy.sock" # To listen on an UDP socket, uncomment this line: CONTROL_SOCK=udp:127.0.0.1:22222 LISTEN_ADDR=[external_ip] # Additional options that are passed to the daemon. EXTRA_OPTS="-l ${LISTEN_ADDR}" /usr/sbin# ------------- It seems to be running: ----------- /etc/init.d# ./rtpproxy start Starting RTP relay: rtpproxy. /etc/init.d# netstat -an|grep 22222 udp 0 0 127.0.0.1:22222 0.0.0.0:* /etc/init.d# ----------------- Here is my kamailio configuration, default as is installed: ------------------------------------------- #!KAMAILIO # # Kamailio (OpenSER) SIP Server v3.1 - default configuration script # - web: http://www.kamailio.org # - git: http://sip-router.org # # Direct your questions about this file to: <sr-users(a)lists.sip-router.org> # # Refer to the Core CookBook at http://www.kamailio.org/dokuwiki/doku.php # for an explanation of possible statements, functions and parameters. # # Several features can be enabled using '#!define WITH_FEATURE' directives: # # *** To run in debug mode: # - define WITH_DEBUG # # *** To enable mysql: # - define WITH_MYSQL # # *** To enable authentication execute: # - enable mysql # - define WITH_AUTH # - add users using 'kamctl' # # *** To enable IP authentication execute: # - enable mysql # - enable authentication # - define WITH_IPAUTH # - add IP addresses with group id '1' to 'address' table # # *** To enable persistent user location execute: # - enable mysql # - define WITH_USRLOCDB # # *** To enable presence server execute: # - enable mysql # - define WITH_PRESENCE # # *** To enable nat traversal execute: # - define WITH_NAT # - install RTPProxy: http://www.rtpproxy.org # - start RTPProxy: # rtpproxy -l _your_public_ip_ -s udp:localhost:7722 # # *** To enable PSTN gateway routing execute: # - define WITH_PSTN # - set the value of pstn.gw_ip # - check route[PSTN] for regexp routing condition # # *** To enable database aliases lookup execute: # - enable mysql # - define WITH_ALIASDB # # *** To enable multi-domain support execute: # - enable mysql # - define WITH_MULTIDOMAIN # # *** To enable TLS support execute: # - adjust CFGDIR/tls.cfg as needed # - define WITH_TLS # # *** To enable XMLRPC support execute: # - define WITH_XMLRPC # - adjust route[XMLRPC] for access policy # # *** To enable anti-flood detection execute: # - adjust pike and htable=>ipban settings as needed (default is # block if more than 16 requests in 2 seconds and ban for 300 seconds) # - define WITH_ANTIFLOOD # # *** To enhance accounting execute: # - enable mysql # - define WITH_ACCDB # - add following columns to database #!ifdef ACCDB_COMMENT ALTER TABLE acc ADD COLUMN src_user VARCHAR(64) NOT NULL DEFAULT ''; ALTER TABLE acc ADD COLUMN src_domain VARCHAR(128) NOT NULL DEFAULT ''; ALTER TABLE acc ADD COLUMN dst_ouser VARCHAR(64) NOT NULL DEFAULT ''; ALTER TABLE acc ADD COLUMN dst_user VARCHAR(64) NOT NULL DEFAULT ''; ALTER TABLE acc ADD COLUMN dst_domain VARCHAR(128) NOT NULL DEFAULT ''; ALTER TABLE missed_calls ADD COLUMN src_user VARCHAR(64) NOT NULL DEFAULT ''; ALTER TABLE missed_calls ADD COLUMN src_domain VARCHAR(128) NOT NULL DEFAULT ''; ALTER TABLE missed_calls ADD COLUMN dst_ouser VARCHAR(64) NOT NULL DEFAULT ''; ALTER TABLE missed_calls ADD COLUMN dst_user VARCHAR(64) NOT NULL DEFAULT ''; ALTER TABLE missed_calls ADD COLUMN dst_domain VARCHAR(128) NOT NULL DEFAULT ''; #!endif ####### Defined Values ######### # *** Value defines - IDs used later in config #!ifdef WITH_MYSQL # - database URL - used to connect to database server by modules such # as: auth_db, acc, usrloc, a.s.o. #!define ""mysql:[my_mysql_db_config]"" "mysql://openser:openserrw@localhost/openser" #!endif #!ifdef WITH_MULTIDOMAIN # - the value for 'use_domain' parameters #!define MULTIDOMAIN 1 #!else #!define MULTIDOMAIN 0 #!endif # - flags # FLT_ - per transaction (message) flags # FLB_ - per branch flags #!define FLT_ACC 1 #!define FLT_ACCMISSED 2 #!define FLT_ACCFAILED 3 #!define FLT_NATS 5 #!define FLB_NATB 6 #!define FLB_NATSIPPING 7 ####### Global Parameters ######### #!ifdef WITH_DEBUG debug=2 log_stderror=no #!else debug=2 log_stderror=no #!endif memdbg=5 memlog=5 log_facility=LOG_DAEMON fork=yes children=4 /* uncomment the next line to disable TCP (default on) */ disable_tcp=no /* uncomment the next line to disable the auto discovery of local aliases based on reverse DNS on IPs (default on) */ #auto_aliases=no /* add local domain aliases */ /* uncomment and configure the following line if you want Kamailio to bind on a specific interface/port/proto (default bind on all available) */ listen=udp:[external_ip]:5060 listen=tcp:[external_ip]:5062 listen=tls:[external_ip]:5061 /* port to listen to * - can be specified more than once if needed to listen on many ports */ port=5060 port=5062 tls_port_no=5061 enable_tls=yes #!ifdef WITH_TLS enable_tls=yes #!endif ####### Custom Parameters ######### # These parameters can be modified runtime via RPC interface # - see the documentation of 'cfg_rpc' module. # # Format: group.id = value 'desc' description # Access: $sel(cfg_get.group.id) or @cfg_get.group.id # #!ifdef WITH_PSTN # PSTN GW Routing # # - pstn.gw_ip: valid IP or hostname as string value, example: # pstn.gw_ip = "10.0.0.101" desc "My PSTN GW Address" # # - by default is empty to avoid misrouting #pstn.gw_ip = "" desc "PSTN GW Address" #!endif ####### Modules Section ######## # set paths to location of modules #!ifdef LOCAL_TEST_RUN mpath="modules_k:modules" #!else mpath="/usr/lib/kamailio/modules_k/:/usr/lib/kamailio/modules/" #!endif #!ifdef WITH_MYSQL loadmodule "db_mysql.so" #!endif loadmodule "mi_fifo.so" loadmodule "kex.so" loadmodule "tm.so" loadmodule "tmx.so" loadmodule "sl.so" loadmodule "rr.so" loadmodule "pv.so" loadmodule "maxfwd.so" loadmodule "usrloc.so" loadmodule "registrar.so" loadmodule "textops.so" loadmodule "siputils.so" loadmodule "xlog.so" loadmodule "sanity.so" loadmodule "ctl.so" loadmodule "mi_rpc.so" loadmodule "acc.so" loadmodule "tls.so" modparam("tls", "config", "/etc/kamailio/tls.cfg") #!ifdef WITH_AUTH loadmodule "auth.so" loadmodule "auth_db.so" #!ifdef WITH_IPAUTH loadmodule "permissions.so" #!endif #!endif #!ifdef WITH_ALIASDB loadmodule "alias_db.so" #!endif #!ifdef WITH_MULTIDOMAIN loadmodule "domain.so" #!endif #!ifdef WITH_PRESENCE loadmodule "presence.so" loadmodule "presence_xml.so" #!endif #!ifdef WITH_NAT loadmodule "nathelper.so" loadmodule "rtpproxy.so" #!endif #!ifdef WITH_TLS loadmodule "tls.so" #!endif #!ifdef WITH_ANTIFLOOD loadmodule "htable.so" loadmodule "pike.so" #!endif #!ifdef WITH_XMLRPC loadmodule "xmlrpc.so" #!endif # ----------------- setting module-specific parameters --------------- # ----- mi_fifo params ----- modparam("mi_fifo", "fifo_name", "/tmp/kamailio_fifo") # ----- tm params ----- # auto-discard branches from previous serial forking leg modparam("tm", "failure_reply_mode", 3) # default retransmission timeout: 30sec modparam("tm", "fr_timer", 30000) # default invite retransmission timeout after 1xx: 120sec modparam("tm", "fr_inv_timer", 120000) # ----- rr params ----- # add value to ;lr param to cope with most of the UAs modparam("rr", "enable_full_lr", 1) # do not append from tag to the RR (no need for this script) modparam("rr", "append_fromtag", 0) # ----- registrar params ----- modparam("registrar", "method_filtering", 1) /* uncomment the next line to disable parallel forking via location */ # modparam("registrar", "append_branches", 0) /* uncomment the next line not to allow more than 10 contacts per AOR */ #modparam("registrar", "max_contacts", 10) # ----- acc params ----- /* what special events should be accounted ? */ modparam("acc", "early_media", 0) modparam("acc", "report_ack", 0) modparam("acc", "report_cancels", 0) /* 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", "log_flag", FLT_ACC) modparam("acc", "log_missed_flag", FLT_ACCMISSED) modparam("acc", "log_extra", "src_user=$fU;src_domain=$fd;dst_ouser=$tU;dst_user=$rU;dst_domain=$rd") modparam("acc", "failed_transaction_flag", FLT_ACCFAILED) /* enhanced DB accounting */ #!ifdef WITH_ACCDB modparam("acc", "db_flag", FLT_ACC) modparam("acc", "db_missed_flag", FLT_ACCMISSED) modparam("acc", "db_url", ""[my_mysql_db_config]"") modparam("acc", "db_extra", "src_user=$fU;src_domain=$fd;dst_ouser=$tU;dst_user=$rU;dst_domain=$rd") #!endif # ----- usrloc params ----- /* enable DB persistency for location entries */ #!ifdef WITH_USRLOCDB modparam("usrloc", "db_url", "[my_mysql_db_config]") modparam("usrloc", "db_mode", 2) modparam("usrloc", "use_domain", MULTIDOMAIN) #!endif # ----- auth_db params ----- #!ifdef WITH_AUTH modparam("auth_db", "db_url", ""[my_mysql_db_config]"") modparam("auth_db", "calculate_ha1", yes) modparam("auth_db", "password_column", "password") modparam("auth_db", "load_credentials", "") modparam("auth_db", "use_domain", MULTIDOMAIN) # ----- permissions params ----- #!ifdef WITH_IPAUTH modparam("permissions", "db_url", "[my_mysql_db_config]") modparam("permissions", "db_mode", 1) #!endif #!endif # ----- alias_db params ----- #!ifdef WITH_ALIASDB modparam("alias_db", "db_url", "[my_mysql_db_config]") modparam("alias_db", "use_domain", MULTIDOMAIN) #!endif # ----- domain params ----- #!ifdef WITH_MULTIDOMAIN modparam("domain", "db_url", "[my_mysql_db_config]") # use caching modparam("domain", "db_mode", 1) # register callback to match myself condition with domains list modparam("domain", "register_myself", 1) #!endif #!ifdef WITH_PRESENCE # ----- presence params ----- modparam("presence", "db_url", "[my_mysql_db_config]") # ----- presence_xml params ----- modparam("presence_xml", "db_url", "[my_mysql_db_config]") modparam("presence_xml", "force_active", 1) #!endif #!ifdef WITH_NAT # ----- rtpproxy params ----- modparam("rtpproxy", "rtpproxy_sock", "udp:127.0.0.1:22222") # ----- nathelper params ----- modparam("nathelper", "natping_interval", 30) modparam("nathelper", "ping_nated_only", 1) modparam("nathelper", "sipping_bflag", FLB_NATSIPPING) modparam("nathelper", "sipping_from", "sip:pinger@[mydomain]") # params needed for NAT traversal in other modules modparam("nathelper|registrar", "received_avp", "$avp(RECEIVED)") modparam("usrloc", "nat_bflag", FLB_NATB) #!endif #!ifdef WITH_TLS # ----- tls params ----- modparam("tls", "config", "/etc/kamailio/tls.cfg") modparam("tls", "tls_debug", 10) #!endif #!ifdef WITH_ANTIFLOOD # ----- pike params ----- modparam("pike", "sampling_time_unit", 2) modparam("pike", "reqs_density_per_unit", 16) modparam("pike", "remove_latency", 4) # ----- htable params ----- # ip ban htable with autoexpire after 5 minutes modparam("htable", "htable", "ipban=>size=8;autoexpire=300;") #!endif #!ifdef WITH_XMLRPC # ----- xmlrpc params ----- modparam("xmlrpc", "route", "XMLRPC"); modparam("xmlrpc", "url_match", "^/RPC") #!endif ####### Routing Logic ######## # Main SIP request routing logic # - processing of any incoming SIP request starts with this route route { # per request initial checks route(REQINIT); # NAT detection route(NAT); # handle requests within SIP dialogs route(WITHINDLG); ### only initial requests (no To tag) # CANCEL processing if (is_method("CANCEL")) { if (t_check_trans()) t_relay(); exit; } t_check_trans(); # authentication route(AUTH); # record routing for dialog forming requests (in case they are routed) # - remove preloaded route headers remove_hf("Route"); if (is_method("INVITE|SUBSCRIBE")) record_route(); # account only INVITEs if (is_method("INVITE")) { setflag(FLT_ACC); # do accounting } # dispatch requests to foreign domains route(SIPOUT); ### requests for my local domains # handle presence related requests route(PRESENCE); # handle registrations route(REGISTRAR); if ($rU==$null) { # request with no Username in RURI sl_send_reply("484","Address Incomplete"); exit; } # dispatch destinations to PSTN route(PSTN); # user location service route(LOCATION); route(RELAY); } route[RELAY] { #!ifdef WITH_NAT if (check_route_param("nat=yes")) { setbflag(FLB_NATB); } if (isflagset(FLT_NATS) || isbflagset(FLB_NATB)) { route(RTPPROXY); } #!endif /* example how to enable some additional event routes */ if (is_method("INVITE")) { #t_on_branch("BRANCH_ONE"); t_on_reply("REPLY_ONE"); t_on_failure("FAIL_ONE"); } if (!t_relay()) { sl_reply_error(); } exit; } # Per SIP request initial checks route[REQINIT] { #!ifdef WITH_ANTIFLOOD # flood dection from same IP and traffic ban for a while # be sure you exclude checking trusted peers, such as pstn gateways # - local host excluded (e.g., loop to self) if(src_ip!=myself) { if($sht(ipban=>$si)!=$null) { # ip is already blocked xdbg("request from blocked IP - $rm from $fu (IP:$si:$sp)\n"); exit; } if (!pike_check_req()) { xlog("L_ALERT","ALERT: pike blocking $rm from $fu (IP:$si:$sp)\n"); $sht(ipban=>$si) = 1; exit; } } #!endif if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; } if(!sanity_check("1511", "7")) { xlog("Malformed SIP message from $si:$sp\n"); exit; } } # Handle requests within SIP dialogs route[WITHINDLG] { if (has_totag()) { # sequential request withing a dialog should # take the path determined by record-routing if (loose_route()) { if (is_method("BYE")) { setflag(FLT_ACC); # do accounting ... setflag(FLT_ACCFAILED); # ... even if the transaction fails } route(RELAY); } else { if (is_method("SUBSCRIBE") && uri == myself) { # in-dialog subscribe requests route(PRESENCE); exit; } if ( is_method("ACK") ) { if ( t_check_trans() ) { # no loose-route, but stateful ACK; # must be an ACK after a 487 # or e.g. 404 from upstream server t_relay(); exit; } else { # ACK without matching transaction ... ignore and discard exit; } } sl_send_reply("404","Not here"); } exit; } } # Handle SIP registrations route[REGISTRAR] { if (is_method("REGISTER")) { if(isflagset(FLT_NATS)) { setbflag(FLB_NATB); # uncomment next line to do SIP NAT pinging setbflag(FLB_NATSIPPING); } if (!save("location")) sl_reply_error(); exit; } } # USER location service route[LOCATION] { #!ifdef WITH_ALIASDB # search in DB-based aliases alias_db_lookup("dbaliases"); #!endif if (!lookup("location")) { switch ($rc) { case -1: case -3: t_newtran(); t_reply("404", "Not Found"); exit; case -2: sl_send_reply("405", "Method Not Allowed"); exit; } } # when routing via usrloc, log the missed calls also if (is_method("INVITE")) { setflag(FLT_ACCMISSED); } } # Presence server route route[PRESENCE] { if(!is_method("PUBLISH|SUBSCRIBE")) return; #!ifdef WITH_PRESENCE if (!t_newtran()) { sl_reply_error(); exit; }; if(is_method("PUBLISH")) { handle_publish(); t_release(); } else if( is_method("SUBSCRIBE")) { handle_subscribe(); t_release(); } exit; #!endif # if presence enabled, this part will not be executed if (is_method("PUBLISH") || $rU==$null) { sl_send_reply("404", "Not here"); exit; } return; } # Authentication route route[AUTH] { #!ifdef WITH_AUTH if (is_method("REGISTER")) { # authenticate the REGISTER requests (uncomment to enable auth) if (!www_authorize("$td", "subscriber")) { www_challenge("$td", "0"); exit; } if ($au!=$tU) { sl_send_reply("403","Forbidden auth ID"); exit; } } else { #!ifdef WITH_IPAUTH if(allow_source_address()) { # source IP allowed return; } #!endif # authenticate if from local subscriber if (from_uri==myself) { if (!proxy_authorize("$fd", "subscriber")) { proxy_challenge("$fd", "0"); exit; } if (is_method("PUBLISH")) { if ($au!=$tU) { sl_send_reply("403","Forbidden auth ID"); exit; } } else { if ($au!=$fU) { sl_send_reply("403","Forbidden auth ID"); exit; } } consume_credentials(); # caller authenticated } else { # caller is not local subscriber, then check if it calls # a local destination, otherwise deny, not an open relay here if (!uri==myself) { sl_send_reply("403","Not relaying"); exit; } } } #!endif return; } # Caller NAT detection route route[NAT] { #!ifdef WITH_NAT force_rport(); if (nat_uac_test("19")) { if (method=="REGISTER") { fix_nated_register(); } else { fix_nated_contact(); } setflag(FLT_NATS); } #!endif return; } # RTPProxy control route[RTPPROXY] { #!ifdef WITH_NAT if (is_method("BYE")) { unforce_rtp_proxy(); } else if (is_method("INVITE")){ force_rtp_proxy(); } if (!has_totag()) add_rr_param(";nat=yes"); #!endif return; } # Routing to foreign domains route[SIPOUT] { if (!uri==myself) { append_hf("P-hint: outbound\r\n"); route(RELAY); } } # PSTN GW routing route[PSTN] { #!ifdef WITH_PSTN # check if PSTN GW IP is defined if (strempty($sel(cfg_get.pstn.gw_ip))) { xlog("SCRIPT: PSTN rotuing enabled but pstn.gw_ip not defined\n"); return; } # route to PSTN dialed numbers starting with '+' or '00' # (international format) # - update the condition to match your dialing rules for PSTN routing if(!($rU=~"^(\+|00)[1-9][0-9]{3,20}$")) return; # only local users allowed to call if(from_uri!=myself) { sl_send_reply("403", "Not Allowed"); exit; } $ru = "sip:" + $rU + "@" + $sel(cfg_get.pstn.gw_ip); route(RELAY); exit; #!endif return; } # XMLRPC routing #!ifdef WITH_XMLRPC route[XMLRPC] { # allow XMLRPC from localhost if ((method=="POST" || method=="GET") && (src_ip==127.0.0.1)) { # close connection only for xmlrpclib user agents (there is a bug in # xmlrpclib: it waits for EOF before interpreting the response). if ($hdr(User-Agent) =~ "xmlrpclib") set_reply_close(); set_reply_no_connect(); dispatch_rpc(); exit; } send_reply("403", "Forbidden"); exit; } #!endif # Sample branch router branch_route[BRANCH_ONE] { xdbg("new branch at $ru\n"); } # Sample onreply route onreply_route[REPLY_ONE] { xdbg("incoming reply\n"); #!ifdef WITH_NAT if ((isflagset(FLT_NATS) || isbflagset(FLB_NATB)) && status=~"(183)|(2[0-9][0-9])") { force_rtp_proxy(); } if (isbflagset("6")) { fix_nated_contact(); } #!endif } # Sample failure route failure_route[FAIL_ONE] { #!ifdef WITH_NAT if (is_method("INVITE") && (isbflagset(FLB_NATB) || isflagset(FLT_NATS))) { unforce_rtp_proxy(); } #!endif if (t_is_canceled()) { 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(); ##} }

2 2

postgres in Kamailio 3.1.2
by Bruno Bresciani 24 Feb '11

24 Feb '11

Hi, I configure the Kamailio 3.1.2 with postgres but I cann't start. In the log file is generated the following error: ** ERROR: load_module: could not open module </home2/local/kamailio/lib/kamailio/modules/db_ postgres.so>: /home2/local/kamailio/lib/kamailio/modules/db_postgres.so: undefined symbol: PQdescribePrepared Why this error is generated? Best Regards

2 1

tcp_persistent_flag
by Bruno Bresciani 24 Feb '11

24 Feb '11

Hi, there is in kamailio 3.1.2 some exported parameter that work as tcp_persistent_flag paramenter? I want to keep alive the connections TCP/TLS as long as the register contact is valid. Best Regards

2 1

dialplan regex confusion
by thrillerbee 24 Feb '11

24 Feb '11

I'm using the following in dialplan: id | dpid | pr | match_op | match_exp | match_len | subst_exp | repl_exp | attrs ----+------+----+----------+----------------------------------------+-----------+----------------------------------------------+----------+---------------------------------- 3 | 3 | 0 | 1 | ^30\d{3}#\+?1?[2-9]\d{2}[2-9]\d{6}$ | 0 | ^(30\d{3}#)(\+?1?)([2-9]\d{2}[2-9]\d{6}$) | \11\3 | normalize prefixed domestic A R-URI goes in as 30001#12345678910 It comes out as 30001#*\1*12345678910 Can someone help me understand why? I'd expect to be exactly what it was originally but for some reason '\1' is thrown in the middle... Thanks, Ryan

2 2

pipelimit db schema
by thrillerbee 24 Feb '11

24 Feb '11

Can anyone point me to the db schema for the new pipelimit module? Thanks, Ryan

3 6

kamctl db exec
by 侯旭光 24 Feb '11

24 Feb '11

Hello How to use "kamctl db exec <query> " function? My SQL_ENGINE is MySQL How to write the command line when I want to do the query "select * from acc" with kamctl db tool? thanks

2 1

NAT Traversal
by Spinov Evgeniy 24 Feb '11

24 Feb '11

Hello, all. Using nathelper + rtpproxy for subj. Kamailio has public and private network interfaces. Asterisk is only private. RTP Proxy is working in bridge mode and relaying traffic from UAC to Asterisks. Everything is working fine, except one configuration. When the client is behind router ( a specific one, I do not have an access there to check ), and this UAC is making a call to other public extension, which is behind router, then RTP Proxy is relaying traffic to the caller, using another UDP port, then the packets arrive. For instance: UAC 1 -> UAC 2 PUBLIC_IP:10 > KAMAILIO_IP:5555 KAMAILIO_IP:5678 > PUBLIC_IP:12 While for the UAC 2 it looks like: PUBLIC_IP:20 > KAMAILIO_IP:6767 KAMAILIO_IP:4564 > PUBLIC_IP:20 The source and destination UDP ports are the same. As result, I can hear UAC 1 and he cannot hear me. In case of we have UAC 3, which is behind other router, call is working fine with same configuration. "It's routers fault" you can say, but in the same configuration ( I mean network, not kamailio ) it worked, but when RTPProxy was not in bridge mode and Kamailio and Asterisks were in public network. Reinvites are not allowed in both cases. The question is, why the source and destination UDP ports are different? Using STUN in first case, cause without it, private IP written in contacts and as result, traffic relayed from Kamailio is incorrect, cause heading to private network which is unreachable. Any ideas where to dig?

1 0

Rtpproxy newbie question
by Marc 24 Feb '11

24 Feb '11

Hi, I installed a kamailio from the debian repository, i use the default configuration. The only enable the tcp and tls transport modes, and configured mysql login. Everyting seems to be working fine. I would need now to configure rtprpoxy, but i just cant make it work. My goal is to force rtpproxy for all calls. Any help is highly appreciated!! Thank you Marc Rtpproxy is installed and seems to be running: This is my rtpproxy configuration: ------------ # Defaults for rtpproxy # The control socket. #CONTROL_SOCK="unix:/var/run/rtpproxy/rtpproxy.sock" # To listen on an UDP socket, uncomment this line: CONTROL_SOCK=udp:127.0.0.1:22222 LISTEN_ADDR=[external_ip] # Additional options that are passed to the daemon. EXTRA_OPTS="-l ${LISTEN_ADDR}" /usr/sbin# ------------- It seems to be running: ----------- /etc/init.d# ./rtpproxy start Starting RTP relay: rtpproxy. /etc/init.d# netstat -an|grep 22222 udp 0 0 127.0.0.1:22222 0.0.0.0:* /etc/init.d# ----------------- Here is my kamailio configuration, default as is installed: ------------------------------------------- #!KAMAILIO # # Kamailio (OpenSER) SIP Server v3.1 - default configuration script # - web: http://www.kamailio.org # - git: http://sip-router.org # # Direct your questions about this file to: <sr-users(a)lists.sip-router.org> # # Refer to the Core CookBook at http://www.kamailio.org/dokuwiki/doku.php # for an explanation of possible statements, functions and parameters. # # Several features can be enabled using '#!define WITH_FEATURE' directives: # # *** To run in debug mode: # - define WITH_DEBUG # # *** To enable mysql: # - define WITH_MYSQL # # *** To enable authentication execute: # - enable mysql # - define WITH_AUTH # - add users using 'kamctl' # # *** To enable IP authentication execute: # - enable mysql # - enable authentication # - define WITH_IPAUTH # - add IP addresses with group id '1' to 'address' table # # *** To enable persistent user location execute: # - enable mysql # - define WITH_USRLOCDB # # *** To enable presence server execute: # - enable mysql # - define WITH_PRESENCE # # *** To enable nat traversal execute: # - define WITH_NAT # - install RTPProxy: http://www.rtpproxy.org # - start RTPProxy: # rtpproxy -l _your_public_ip_ -s udp:localhost:7722 # # *** To enable PSTN gateway routing execute: # - define WITH_PSTN # - set the value of pstn.gw_ip # - check route[PSTN] for regexp routing condition # # *** To enable database aliases lookup execute: # - enable mysql # - define WITH_ALIASDB # # *** To enable multi-domain support execute: # - enable mysql # - define WITH_MULTIDOMAIN # # *** To enable TLS support execute: # - adjust CFGDIR/tls.cfg as needed # - define WITH_TLS # # *** To enable XMLRPC support execute: # - define WITH_XMLRPC # - adjust route[XMLRPC] for access policy # # *** To enable anti-flood detection execute: # - adjust pike and htable=>ipban settings as needed (default is # block if more than 16 requests in 2 seconds and ban for 300 seconds) # - define WITH_ANTIFLOOD # # *** To enhance accounting execute: # - enable mysql # - define WITH_ACCDB # - add following columns to database #!ifdef ACCDB_COMMENT ALTER TABLE acc ADD COLUMN src_user VARCHAR(64) NOT NULL DEFAULT ''; ALTER TABLE acc ADD COLUMN src_domain VARCHAR(128) NOT NULL DEFAULT ''; ALTER TABLE acc ADD COLUMN dst_ouser VARCHAR(64) NOT NULL DEFAULT ''; ALTER TABLE acc ADD COLUMN dst_user VARCHAR(64) NOT NULL DEFAULT ''; ALTER TABLE acc ADD COLUMN dst_domain VARCHAR(128) NOT NULL DEFAULT ''; ALTER TABLE missed_calls ADD COLUMN src_user VARCHAR(64) NOT NULL DEFAULT ''; ALTER TABLE missed_calls ADD COLUMN src_domain VARCHAR(128) NOT NULL DEFAULT ''; ALTER TABLE missed_calls ADD COLUMN dst_ouser VARCHAR(64) NOT NULL DEFAULT ''; ALTER TABLE missed_calls ADD COLUMN dst_user VARCHAR(64) NOT NULL DEFAULT ''; ALTER TABLE missed_calls ADD COLUMN dst_domain VARCHAR(128) NOT NULL DEFAULT ''; #!endif ####### Defined Values ######### # *** Value defines - IDs used later in config #!ifdef WITH_MYSQL # - database URL - used to connect to database server by modules such # as: auth_db, acc, usrloc, a.s.o. #!define ""mysql:[my_mysql_db_config]"" "mysql://openser:openserrw@localhost/openser" #!endif #!ifdef WITH_MULTIDOMAIN # - the value for 'use_domain' parameters #!define MULTIDOMAIN 1 #!else #!define MULTIDOMAIN 0 #!endif # - flags # FLT_ - per transaction (message) flags # FLB_ - per branch flags #!define FLT_ACC 1 #!define FLT_ACCMISSED 2 #!define FLT_ACCFAILED 3 #!define FLT_NATS 5 #!define FLB_NATB 6 #!define FLB_NATSIPPING 7 ####### Global Parameters ######### #!ifdef WITH_DEBUG debug=2 log_stderror=no #!else debug=2 log_stderror=no #!endif memdbg=5 memlog=5 log_facility=LOG_DAEMON fork=yes children=4 /* uncomment the next line to disable TCP (default on) */ disable_tcp=no /* uncomment the next line to disable the auto discovery of local aliases based on reverse DNS on IPs (default on) */ #auto_aliases=no /* add local domain aliases */ /* uncomment and configure the following line if you want Kamailio to bind on a specific interface/port/proto (default bind on all available) */ listen=udp:[external_ip]:5060 listen=tcp:[external_ip]:5062 listen=tls:[external_ip]:5061 /* port to listen to * - can be specified more than once if needed to listen on many ports */ port=5060 port=5062 tls_port_no=5061 enable_tls=yes #!ifdef WITH_TLS enable_tls=yes #!endif ####### Custom Parameters ######### # These parameters can be modified runtime via RPC interface # - see the documentation of 'cfg_rpc' module. # # Format: group.id = value 'desc' description # Access: $sel(cfg_get.group.id) or @cfg_get.group.id # #!ifdef WITH_PSTN # PSTN GW Routing # # - pstn.gw_ip: valid IP or hostname as string value, example: # pstn.gw_ip = "10.0.0.101" desc "My PSTN GW Address" # # - by default is empty to avoid misrouting #pstn.gw_ip = "" desc "PSTN GW Address" #!endif ####### Modules Section ######## # set paths to location of modules #!ifdef LOCAL_TEST_RUN mpath="modules_k:modules" #!else mpath="/usr/lib/kamailio/modules_k/:/usr/lib/kamailio/modules/" #!endif #!ifdef WITH_MYSQL loadmodule "db_mysql.so" #!endif loadmodule "mi_fifo.so" loadmodule "kex.so" loadmodule "tm.so" loadmodule "tmx.so" loadmodule "sl.so" loadmodule "rr.so" loadmodule "pv.so" loadmodule "maxfwd.so" loadmodule "usrloc.so" loadmodule "registrar.so" loadmodule "textops.so" loadmodule "siputils.so" loadmodule "xlog.so" loadmodule "sanity.so" loadmodule "ctl.so" loadmodule "mi_rpc.so" loadmodule "acc.so" loadmodule "tls.so" modparam("tls", "config", "/etc/kamailio/tls.cfg") #!ifdef WITH_AUTH loadmodule "auth.so" loadmodule "auth_db.so" #!ifdef WITH_IPAUTH loadmodule "permissions.so" #!endif #!endif #!ifdef WITH_ALIASDB loadmodule "alias_db.so" #!endif #!ifdef WITH_MULTIDOMAIN loadmodule "domain.so" #!endif #!ifdef WITH_PRESENCE loadmodule "presence.so" loadmodule "presence_xml.so" #!endif #!ifdef WITH_NAT loadmodule "nathelper.so" loadmodule "rtpproxy.so" #!endif #!ifdef WITH_TLS loadmodule "tls.so" #!endif #!ifdef WITH_ANTIFLOOD loadmodule "htable.so" loadmodule "pike.so" #!endif #!ifdef WITH_XMLRPC loadmodule "xmlrpc.so" #!endif # ----------------- setting module-specific parameters --------------- # ----- mi_fifo params ----- modparam("mi_fifo", "fifo_name", "/tmp/kamailio_fifo") # ----- tm params ----- # auto-discard branches from previous serial forking leg modparam("tm", "failure_reply_mode", 3) # default retransmission timeout: 30sec modparam("tm", "fr_timer", 30000) # default invite retransmission timeout after 1xx: 120sec modparam("tm", "fr_inv_timer", 120000) # ----- rr params ----- # add value to ;lr param to cope with most of the UAs modparam("rr", "enable_full_lr", 1) # do not append from tag to the RR (no need for this script) modparam("rr", "append_fromtag", 0) # ----- registrar params ----- modparam("registrar", "method_filtering", 1) /* uncomment the next line to disable parallel forking via location */ # modparam("registrar", "append_branches", 0) /* uncomment the next line not to allow more than 10 contacts per AOR */ #modparam("registrar", "max_contacts", 10) # ----- acc params ----- /* what special events should be accounted ? */ modparam("acc", "early_media", 0) modparam("acc", "report_ack", 0) modparam("acc", "report_cancels", 0) /* 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", "log_flag", FLT_ACC) modparam("acc", "log_missed_flag", FLT_ACCMISSED) modparam("acc", "log_extra", "src_user=$fU;src_domain=$fd;dst_ouser=$tU;dst_user=$rU;dst_domain=$rd") modparam("acc", "failed_transaction_flag", FLT_ACCFAILED) /* enhanced DB accounting */ #!ifdef WITH_ACCDB modparam("acc", "db_flag", FLT_ACC) modparam("acc", "db_missed_flag", FLT_ACCMISSED) modparam("acc", "db_url", ""[my_mysql_db_config]"") modparam("acc", "db_extra", "src_user=$fU;src_domain=$fd;dst_ouser=$tU;dst_user=$rU;dst_domain=$rd") #!endif # ----- usrloc params ----- /* enable DB persistency for location entries */ #!ifdef WITH_USRLOCDB modparam("usrloc", "db_url", "[my_mysql_db_config]") modparam("usrloc", "db_mode", 2) modparam("usrloc", "use_domain", MULTIDOMAIN) #!endif # ----- auth_db params ----- #!ifdef WITH_AUTH modparam("auth_db", "db_url", ""[my_mysql_db_config]"") modparam("auth_db", "calculate_ha1", yes) modparam("auth_db", "password_column", "password") modparam("auth_db", "load_credentials", "") modparam("auth_db", "use_domain", MULTIDOMAIN) # ----- permissions params ----- #!ifdef WITH_IPAUTH modparam("permissions", "db_url", "[my_mysql_db_config]") modparam("permissions", "db_mode", 1) #!endif #!endif # ----- alias_db params ----- #!ifdef WITH_ALIASDB modparam("alias_db", "db_url", "[my_mysql_db_config]") modparam("alias_db", "use_domain", MULTIDOMAIN) #!endif # ----- domain params ----- #!ifdef WITH_MULTIDOMAIN modparam("domain", "db_url", "[my_mysql_db_config]") # use caching modparam("domain", "db_mode", 1) # register callback to match myself condition with domains list modparam("domain", "register_myself", 1) #!endif #!ifdef WITH_PRESENCE # ----- presence params ----- modparam("presence", "db_url", "[my_mysql_db_config]") # ----- presence_xml params ----- modparam("presence_xml", "db_url", "[my_mysql_db_config]") modparam("presence_xml", "force_active", 1) #!endif #!ifdef WITH_NAT # ----- rtpproxy params ----- modparam("rtpproxy", "rtpproxy_sock", "udp:127.0.0.1:22222") # ----- nathelper params ----- modparam("nathelper", "natping_interval", 30) modparam("nathelper", "ping_nated_only", 1) modparam("nathelper", "sipping_bflag", FLB_NATSIPPING) modparam("nathelper", "sipping_from", "sip:pinger@[mydomain]") # params needed for NAT traversal in other modules modparam("nathelper|registrar", "received_avp", "$avp(RECEIVED)") modparam("usrloc", "nat_bflag", FLB_NATB) #!endif #!ifdef WITH_TLS # ----- tls params ----- modparam("tls", "config", "/etc/kamailio/tls.cfg") modparam("tls", "tls_debug", 10) #!endif #!ifdef WITH_ANTIFLOOD # ----- pike params ----- modparam("pike", "sampling_time_unit", 2) modparam("pike", "reqs_density_per_unit", 16) modparam("pike", "remove_latency", 4) # ----- htable params ----- # ip ban htable with autoexpire after 5 minutes modparam("htable", "htable", "ipban=>size=8;autoexpire=300;") #!endif #!ifdef WITH_XMLRPC # ----- xmlrpc params ----- modparam("xmlrpc", "route", "XMLRPC"); modparam("xmlrpc", "url_match", "^/RPC") #!endif ####### Routing Logic ######## # Main SIP request routing logic # - processing of any incoming SIP request starts with this route route { # per request initial checks route(REQINIT); # NAT detection route(NAT); # handle requests within SIP dialogs route(WITHINDLG); ### only initial requests (no To tag) # CANCEL processing if (is_method("CANCEL")) { if (t_check_trans()) t_relay(); exit; } t_check_trans(); # authentication route(AUTH); # record routing for dialog forming requests (in case they are routed) # - remove preloaded route headers remove_hf("Route"); if (is_method("INVITE|SUBSCRIBE")) record_route(); # account only INVITEs if (is_method("INVITE")) { setflag(FLT_ACC); # do accounting } # dispatch requests to foreign domains route(SIPOUT); ### requests for my local domains # handle presence related requests route(PRESENCE); # handle registrations route(REGISTRAR); if ($rU==$null) { # request with no Username in RURI sl_send_reply("484","Address Incomplete"); exit; } # dispatch destinations to PSTN route(PSTN); # user location service route(LOCATION); route(RELAY); } route[RELAY] { #!ifdef WITH_NAT if (check_route_param("nat=yes")) { setbflag(FLB_NATB); } if (isflagset(FLT_NATS) || isbflagset(FLB_NATB)) { route(RTPPROXY); } #!endif /* example how to enable some additional event routes */ if (is_method("INVITE")) { #t_on_branch("BRANCH_ONE"); t_on_reply("REPLY_ONE"); t_on_failure("FAIL_ONE"); } if (!t_relay()) { sl_reply_error(); } exit; } # Per SIP request initial checks route[REQINIT] { #!ifdef WITH_ANTIFLOOD # flood dection from same IP and traffic ban for a while # be sure you exclude checking trusted peers, such as pstn gateways # - local host excluded (e.g., loop to self) if(src_ip!=myself) { if($sht(ipban=>$si)!=$null) { # ip is already blocked xdbg("request from blocked IP - $rm from $fu (IP:$si:$sp)\n"); exit; } if (!pike_check_req()) { xlog("L_ALERT","ALERT: pike blocking $rm from $fu (IP:$si:$sp)\n"); $sht(ipban=>$si) = 1; exit; } } #!endif if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; } if(!sanity_check("1511", "7")) { xlog("Malformed SIP message from $si:$sp\n"); exit; } } # Handle requests within SIP dialogs route[WITHINDLG] { if (has_totag()) { # sequential request withing a dialog should # take the path determined by record-routing if (loose_route()) { if (is_method("BYE")) { setflag(FLT_ACC); # do accounting ... setflag(FLT_ACCFAILED); # ... even if the transaction fails } route(RELAY); } else { if (is_method("SUBSCRIBE") && uri == myself) { # in-dialog subscribe requests route(PRESENCE); exit; } if ( is_method("ACK") ) { if ( t_check_trans() ) { # no loose-route, but stateful ACK; # must be an ACK after a 487 # or e.g. 404 from upstream server t_relay(); exit; } else { # ACK without matching transaction ... ignore and discard exit; } } sl_send_reply("404","Not here"); } exit; } } # Handle SIP registrations route[REGISTRAR] { if (is_method("REGISTER")) { if(isflagset(FLT_NATS)) { setbflag(FLB_NATB); # uncomment next line to do SIP NAT pinging setbflag(FLB_NATSIPPING); } if (!save("location")) sl_reply_error(); exit; } } # USER location service route[LOCATION] { #!ifdef WITH_ALIASDB # search in DB-based aliases alias_db_lookup("dbaliases"); #!endif if (!lookup("location")) { switch ($rc) { case -1: case -3: t_newtran(); t_reply("404", "Not Found"); exit; case -2: sl_send_reply("405", "Method Not Allowed"); exit; } } # when routing via usrloc, log the missed calls also if (is_method("INVITE")) { setflag(FLT_ACCMISSED); } } # Presence server route route[PRESENCE] { if(!is_method("PUBLISH|SUBSCRIBE")) return; #!ifdef WITH_PRESENCE if (!t_newtran()) { sl_reply_error(); exit; }; if(is_method("PUBLISH")) { handle_publish(); t_release(); } else if( is_method("SUBSCRIBE")) { handle_subscribe(); t_release(); } exit; #!endif # if presence enabled, this part will not be executed if (is_method("PUBLISH") || $rU==$null) { sl_send_reply("404", "Not here"); exit; } return; } # Authentication route route[AUTH] { #!ifdef WITH_AUTH if (is_method("REGISTER")) { # authenticate the REGISTER requests (uncomment to enable auth) if (!www_authorize("$td", "subscriber")) { www_challenge("$td", "0"); exit; } if ($au!=$tU) { sl_send_reply("403","Forbidden auth ID"); exit; } } else { #!ifdef WITH_IPAUTH if(allow_source_address()) { # source IP allowed return; } #!endif # authenticate if from local subscriber if (from_uri==myself) { if (!proxy_authorize("$fd", "subscriber")) { proxy_challenge("$fd", "0"); exit; } if (is_method("PUBLISH")) { if ($au!=$tU) { sl_send_reply("403","Forbidden auth ID"); exit; } } else { if ($au!=$fU) { sl_send_reply("403","Forbidden auth ID"); exit; } } consume_credentials(); # caller authenticated } else { # caller is not local subscriber, then check if it calls # a local destination, otherwise deny, not an open relay here if (!uri==myself) { sl_send_reply("403","Not relaying"); exit; } } } #!endif return; } # Caller NAT detection route route[NAT] { #!ifdef WITH_NAT force_rport(); if (nat_uac_test("19")) { if (method=="REGISTER") { fix_nated_register(); } else { fix_nated_contact(); } setflag(FLT_NATS); } #!endif return; } # RTPProxy control route[RTPPROXY] { #!ifdef WITH_NAT if (is_method("BYE")) { unforce_rtp_proxy(); } else if (is_method("INVITE")){ force_rtp_proxy(); } if (!has_totag()) add_rr_param(";nat=yes"); #!endif return; } # Routing to foreign domains route[SIPOUT] { if (!uri==myself) { append_hf("P-hint: outbound\r\n"); route(RELAY); } } # PSTN GW routing route[PSTN] { #!ifdef WITH_PSTN # check if PSTN GW IP is defined if (strempty($sel(cfg_get.pstn.gw_ip))) { xlog("SCRIPT: PSTN rotuing enabled but pstn.gw_ip not defined\n"); return; } # route to PSTN dialed numbers starting with '+' or '00' # (international format) # - update the condition to match your dialing rules for PSTN routing if(!($rU=~"^(\+|00)[1-9][0-9]{3,20}$")) return; # only local users allowed to call if(from_uri!=myself) { sl_send_reply("403", "Not Allowed"); exit; } $ru = "sip:" + $rU + "@" + $sel(cfg_get.pstn.gw_ip); route(RELAY); exit; #!endif return; } # XMLRPC routing #!ifdef WITH_XMLRPC route[XMLRPC] { # allow XMLRPC from localhost if ((method=="POST" || method=="GET") && (src_ip==127.0.0.1)) { # close connection only for xmlrpclib user agents (there is a bug in # xmlrpclib: it waits for EOF before interpreting the response). if ($hdr(User-Agent) =~ "xmlrpclib") set_reply_close(); set_reply_no_connect(); dispatch_rpc(); exit; } send_reply("403", "Forbidden"); exit; } #!endif # Sample branch router branch_route[BRANCH_ONE] { xdbg("new branch at $ru\n"); } # Sample onreply route onreply_route[REPLY_ONE] { xdbg("incoming reply\n"); #!ifdef WITH_NAT if ((isflagset(FLT_NATS) || isbflagset(FLB_NATB)) && status=~"(183)|(2[0-9][0-9])") { force_rtp_proxy(); } if (isbflagset("6")) { fix_nated_contact(); } #!endif } # Sample failure route failure_route[FAIL_ONE] { #!ifdef WITH_NAT if (is_method("INVITE") && (isbflagset(FLB_NATB) || isflagset(FLT_NATS))) { unforce_rtp_proxy(); } #!endif if (t_is_canceled()) { 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(); ##} }

1 0

403 "Not Relaying" problem
by yan wang 24 Feb '11

24 Feb '11

Dear Friends, With Kamailio 3.1.2, after successfully registering, the caller sends INVITE to the proxy, and is always responded with 403 not relaying. I found that in the route[AUTH] subroutine, like below. Regarding the red comparing, it failed. I also check the code, and found Kamailio will use the host name in the From header to compare all the socket's IP address, such as host = mysipserver.com, but socket's ip = 127.0.0.1 or 10.1.1.5. As you can see, this comparing will never be equal.Could anyone show me how to handle this problem? Thanks a lot! # authenticate if from local subscriber if (from_uri==myself) { if (!proxy_authorize("$fd", "subscriber")) { proxy_challenge("$fd", "0"); exit; } if (is_method("PUBLISH")) { if ($au!=$tU) { sl_send_reply("403","Forbidden auth ID"); exit; } } else { if ($au!=$fU) { sl_send_reply("403","Forbidden auth ID"); exit; } } consume_credentials(); # caller authenticated } else { # caller is not local subscriber, then check if it calls # a local destination, otherwise deny, not an open relay here if (!uri==myself) { sl_send_reply("403","Not relaying"); exit; } } Best Regards,Spencer

1 0

how to forward on busy
by x-kamailio＠sidell.org 23 Feb '11

23 Feb '11

Is there an example somewhere that shows how to do forward-on-busy, starting with the kamailio.cfg from version 3.1? Ultimately, I want to use a per-user AVP to obtain the forwarding URI, but just an example that shows how to forward to a fixed URI from the failure route would be great. -- Mark Sidell Partner Forte, Inc. 919-942-7068 fax 919-969-2844 www.forteinc.com

1 0

Re: [SR-Users] Visiting CeBIT 2011 in Hanover (Carsten Bock)
by Dan-Cristian Bogos 23 Feb '11

23 Feb '11

Daniel, I will be there on Thursday/Friday. Cheers. DanB

1 0

422 Session timer too small
by Mino Haluz 23 Feb '11

23 Feb '11

Hi, I see in my cdrtool rarely 422 Session Timer too small - the reason why the call was not initiated. Do you have some suggestion how to fix this ? Maybe SST module ? What is the default value of this timer, so that I could increase it ? kamailio 3.1.0 (i386/linux) 1e204f Thank you, Mino

3 2

kamailio 3.1: forward("10.0.0.10:5060") not working?
by Min Wang 23 Feb '11

23 Feb '11

HI It seems the forward("host:port") not working in the kamailio 3.1? the simple route like: route { forward("67.154.xx.xx:5080"); } the error is: <core> [proxy.c:278]: ERROR: mk_proxy: could not resolve hostname: "67.154.xx.xx:5080" Anything missing? the detailed log is: 0(8500) DEBUG: <core> [sr_module.c:625]: find_export_record: found <load_tm> in module tm [/usr/lib/kamailio/modules/tm.so] 0(8500) DEBUG: <core> [sr_module.c:625]: find_export_record: found <t_newtran> in module tm [/usr/lib/kamailio/modules/tm.so] 0(8500) DEBUG: <core> [sr_module.c:625]: find_export_record: found <t_relay_to_tcp> in module tm [/usr/lib/kamailio/modules/tm.so] 0(8500) DEBUG: <core> [sr_module.c:625]: find_export_record: found <t_relay_to_udp> in module tm [/usr/lib/kamailio/modules/tm.so] 0(8500) DEBUG: <core> [sr_module.c:625]: find_export_record: found <t_relay> in module tm [/usr/lib/kamailio/modules/tm.so] 0(8500) DEBUG: <core> [sr_module.c:625]: find_export_record: found <t_forward_nonack> in module tm [/usr/lib/kamailio/modules/tm.so] 0(8500) DEBUG: <core> [sr_module.c:625]: find_export_record: found <t_release> in module tm [/usr/lib/kamailio/modules/tm.so] 0(8500) DEBUG: <core> [main.c:2371]: Expect (at least) 18 SER processes in your process list 0(8500) DEBUG: <core> [proxy.c:278]: DEBUG: mk_proxy: doing DNS lookup... 0(8500) DEBUG: <core> [dns_cache.c:567]: dns_hash_find(_sip._udp.67.154.xx.xx:5080(28), 33), h=780 0(8500) DEBUG: <core> [resolve.c:727]: get_record: lookup(_sip._udp.67.154.xx.xx.:5080, 33) failed 0(8500) DEBUG: <core> [dns_cache.c:895]: dns_cache_mk_bad_entry(_sip._udp.67.154.xx.xx:5080, 33, 60, 1) 0(8500) DEBUG: <core> [dns_cache.c:828]: dns_cache_add: adding _sip._udp.67.154.xx.xx:5080(28) 33 (flags=1) at 780 0(8500) DEBUG: <core> [dns_cache.c:567]: dns_hash_find(67.154.xx.xx:5080(18), 1), h=16 0(8500) DEBUG: <core> [resolve.c:727]: get_record: lookup(67.154.xx.xx:5080, 1) failed 0(8500) DEBUG: <core> [dns_cache.c:895]: dns_cache_mk_bad_entry(67.154.xx.xx:5080, 1, 60, 1) 0(8500) DEBUG: <core> [dns_cache.c:828]: dns_cache_add: adding 67.154.xx.xx:5080(18) 1 (flags=1) at 16 0(8500) : <core> [proxy.c:278]: ERROR: mk_proxy: could not resolve hostname: "67.154.xx.xx:5080" 0(8500) ERROR: <core> [route.c:1161]: fixing failed (code=-478) at cfg:/etc/kamailio/kamailio.cfg:394 ERROR: error -478 while trying to fix configuration 0(8500) DEBUG: tm [t_funcs.c:122]: DEBUG: tm_shutdown : start 0(8500) DEBUG: tm [t_funcs.c:125]: DEBUG: tm_shutdown : emptying hash table 0(8500) DEBUG: tm [t_funcs.c:127]: DEBUG: tm_shutdown : removing semaphores 0(8500) DEBUG: tm [t_funcs.c:129]: DEBUG: tm_shutdown : destroying tmcb lists 0(8500) DEBUG: tm [t_funcs.c:132]: DEBUG: tm_shutdown : done 0(8500) DEBUG: <core> [mem/shm_mem.c:236]: shm_mem_destroy 0(8500) DEBUG: <core> [mem/shm_mem.c:239]: destroying the shared memory lock thx. -- Kind regards / Mit freundlichen Grüßen Min Wang

2 2

Re: [SR-Users] How to get the dialog information via dlg_list command?
by yan wang 23 Feb '11

23 Feb '11

Hi Daniel, Thanks a lot for your quick reply. I recompile and install the Kamailio as the following page described.http://www.kamailio.org/dokuwiki/doku.php/install:kamailio-3.1.x-… I also successfully created two SIP users: "User1" and "User2". Now the registeration is passed for the two users. But when "User1" sends INVITE to "User2" through the Kamailio proxy, it always response with 403 "Not relaying" and not forward the INVITE to "User2". Could you please give me some help on this case? Thanks. BTW, I have export the environment variable SIP_DOMAIN to "mysipserver.com". And please check the attached enclosed config file and trace. Best Regards,Spencer --- On Wed, 2/23/11, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote: From: Daniel-Constantin Mierla <miconda(a)gmail.com> Subject: Re: [SR-Users] How to get the dialog information via dlg_list command? To: "yan wang" <rtosvip(a)yahoo.com.cn> Cc: sr-users(a)lists.sip-router.org Date: Wednesday, February 23, 2011, 2:42 PM Hello, the problem is you are using the dialog module coming from SER, not the one coming from Kamailio. The loadpath (or mpath) has to include directorins ending in modules_k and modules. I recommend you use kamailio.cfg as a start to build your config and then add the dialog module. Before compiling, when you are using the sources, you have to do: make FLAVOUR=kamailio cfg You can see more at: http://www.kamailio.org/dokuwiki/doku.php/install:kamailio-3.1.x-from-git If you prefer to install deb files (on Debian/Ubuntu), see: http://www.kamailio.org/dokuwiki/doku.php/packages:debs Cheers, Daniel On 2/23/11 7:32 AM, yan wang wrote: Dear Friends, I need your help on the following question: I am using Kamailio 3.1.2. I want to get the dialog information dynamically via the FIFO command "dlg_list" by "kamctl fifo dlg_list". But unfortunately, I could get NOTHING in the output. And the fact is that I have setup 5 pairs SIP calls with the Kamailio SIP proxy. Could anyone show me the clues and how to get the correct dialog information? Thanks. BTW, I attached the config file. Best Regards, Spencer _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- Daniel-Constantin Mierla http://www.asipto.com

1 0

Re: [SR-Users] get_profile_size() function help (Alex Balashov)
by 侯旭光 23 Feb '11

23 Feb '11

On 02/21/2011 04:50 AM, ??? wrote: > ALTER:<core> [main.c 722] : child process 29651 exited by sinal 11 > ALTER:<core> [main.c 725] : core was generated > INFO :<core> [main.c 737] : terminating due to SIGCHILD This is a crash. It's a bug. Then how to get the number of dialogs belonging to a profile?

3 3

How to get the dialog information via dlg_list command?
by yan wang 23 Feb '11

23 Feb '11

Dear Friends, I need your help on the following question: I am using Kamailio 3.1.2. I want to get the dialog information dynamically via the FIFO command "dlg_list" by "kamctl fifo dlg_list". But unfortunately, I could get NOTHING in the output. And the fact is that I have setup 5 pairs SIP calls with the Kamailio SIP proxy. Could anyone show me the clues and how to get the correct dialog information? Thanks. BTW, I attached the config file. Best Regards,Spencer

2 1

Re: [SR-Users] Unable to start Siremis
by jack＠4voice.net 22 Feb '11

22 Feb '11

1 0

Unable to start Siremis
by jack＠4voice.net 22 Feb '11

22 Feb '11

2 1

UAC Module: test registration to a Voip provider
by Matteo Campana 22 Feb '11

22 Feb '11

Hi all, we are using the UAC module ( http://www.kamailio.org/docs/modules/stable/modules_k/uac.html#id2910015) to register the proxy to an external DID provider. I know that the module takes care of sending REGISTER on the basis of credentials stored in uacreg table, but my question is: if I add a new row in the uacreg table, kamailio will register the new username after the database update or I need a restart of kamailio (or some kamailio module)? If I edit the row in uacreg table and I call the rpc command *sercmd uac.reg_dump *I see the old values in the output, but if I restart kamailio I see the new values. Tanks in advance, Matteo

2 1

how to forward on busy
by x-kamailio＠sidell.org 22 Feb '11

22 Feb '11

I'm trying to do something very basic, which is to forward a call to a different number on busy. But, the various things I've tried from the examples don't work. Starting with the kamailio.cfg that is included with version 3.1, what code would I add to forward all busy calls to "sip:foo@bar.com", a target that is not necessarily local to the server? Many thanks! -- Mark Sidell Partner Forte, Inc. 919-942-7068 fax 919-969-2844 www.forteinc.com

2 1

Kamailio/SIP Router in RHEL 5
by Suresh Bhandari 22 Feb '11

22 Feb '11

Hi, I wanted to run Kamailio/SIP Server in RHEL 5 (Being an RHCE, I prefer this :)), but the INSTALL document you provided has no description based on that OS :(. I found that there are no RPMs for this as well. Are you preparing them? or Do you have any plans for that? or you prefer me to change the OS. Thanks and Regards, Suresh.

3 2

Visiting CeBIT 2011 in Hanover
by Daniel-Constantin Mierla 22 Feb '11

22 Feb '11

Hello, I am going to visit CeBIT show this year (first week of March in Hanover, Germany), if anyone else here is there and want to meet for a chat about latest developments in the project and VoIP world, drop me an email, maybe we have some overlapping days and can sit together for a bit. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

3 2

HTABLE problem
by Ricardo Martinez 21 Feb '11

21 Feb '11

Hello I’m trying to use “htable” module with the example to block a user with three time s failed password. When a REGISTER arrives I’m getting this error : Feb 18 17:26:34 /usr/local/sbin/kamailio[5840]: ERROR: <core> [lvalue.c:358]: setting pvar failed Feb 18 17:26:34 /usr/local/sbin/kamailio[5840]: ERROR: <core> [lvalue.c:411]: assignment failed at pos: (322,54-322,81) Feb 18 17:26:34 /usr/local/sbin/kamailio[5840]: ERROR: <core> [lvalue.c:358]: setting pvar failed Feb 18 17:26:34 /usr/local/sbin/kamailio[5840]: ERROR: <core> [lvalue.c:411]: assignment failed at pos: (328,47-328,49) The lines pointing the error are these : 312 if ( !radius_www_authorize("10.0.0.208") ) 313 { 314 switch ($retcode) { 315 case -1: 316 xlog("L_INFO","authentication failed from radius\n"); 317 if($sht(a=>$au::auth_count) == "null") 318 { 319 $sht(a=>$au::auth_count) = 0; 320 } 321 $sht(a=>$au::auth_count) = $sht(a=>$au::auth_count) + 1; 322 if($sht(a=>$au::auth_count) == 3) 323 { 324 xlog("L_INFO","auth failed 3rd time - src ip: $si\n"); 325 } 326 $sht(a=>$au::last_auth) = $Ts; 327 break; 328 case -5: 329 sl_send_reply("403", "Forbidden"); 330 exit; 331 } 332 www_challenge("10.0.0.208", "1"); 333 exit; 334 } What could be the problem? Thanks in advance. Regards, Ricardo.-

2 3

Kamailio Awards 2010
by Daniel-Constantin Mierla 21 Feb '11

21 Feb '11

Hello, almost a tradition by now, being the 4th edition, I published Kamailio Awards for 2010 - a blog post that tries to summarize the top of the activities in the public space related to Kamailio project that happened during the previous year. You can browse it at: http://asipto.com/u/ka10 Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

1 0

AVP Error in version 3.1.0
by Jijo 21 Feb '11

21 Feb '11

Hi All, On register we store the contact in an avp variable and do a t_relay(). After t_relay() the $avp variable becomes null. I printed the value before after t_relay() to determine this behavior. This happens only on registration load test around 2000 subcribers with ( 4 REGISTER/sec). This happens only for one subscriber out of 2000 subscribers. I did the similar test with $var and its working fine. Anybody observed similar behavior with avp? This was working in kamailio 1.4 version. We did the upgrade recently to 3.1.0 and started observing this issue. How do we debug this issue.? Thanks Jijo

2 5

get_profile_size() function help
by 侯旭光 21 Feb '11

21 Feb '11

Hello bother again what's the problem with the function get_profile_size() My script modparam("dialog", "enable_stats", 1) modparam("dialog", "dlg_flag", 4) modparam("dialog", "dlg_mode", 1) modparam("dialog", "db_url", "mysql://openser:openserrw@localhost/openser") modparam("dialog", "profiles_no_value", "inbound ; outbound") ... if(is_method("INVITE")) { ... dlg_manage(); set_dlg_profile("inbound"); ... get_profile_size("inbound","$avp(size)"); ... } ============================================ when program runs to the function get_profile_size(), the proxy will be terminate. log file: ALTER: <core> [main.c 722] : child process 29651 exited by sinal 11 ALTER: <core> [main.c 725] : core was generated INFO : <core> [main.c 737] : terminating due to SIGCHILD ============================================ what' s the problem? Did I use the func wrong? thanks

2 1

pcre mystery or bug in dialplan module?
by Juha Heinanen 21 Feb '11

21 Feb '11

i have in dialplan table record 287 14 10 1 ^(.+)\+358 0 ^(.+):\+358(.+) \1:0\2 and when it is applied to uri Feb 21 08:05:15 sip /usr/sbin/sip-proxy[24071]: INFO: uri <sip:+35892345670@test.fi;user=phone> the resulting uri looks like this: Feb 21 08:05:15 sip /usr/sbin/sip-proxy[24071]: INFO: uri <sip\1:092345670@test.fi;user=phone> i can't figure out, where \1 comes to the result, because \1 is has already produced 'sip' to it. i have added debug to dialplan module and looks like it compiles correct subst and repl expressions: Feb 21 08:05:05 sip /usr/sbin/sip-proxy[24067]: INFO: dialplan [dp_db.c:392]: parsing repl_exp <\1:0\2> Feb 21 08:05:05 sip /usr/sbin/sip-proxy[24067]: INFO: dialplan [dp_db.c:404]: compilig subst_exp <^(.+):\+358(.+)> is there some stupid mistake in the expressions or could it be a bug somewhere? -- juha

1 1

decimal fraction problem
by 侯旭光 20 Feb '11

20 Feb '11

Hello I need to add q value while using function append_branch(),but the function only takes decimal fraction as the parameter. What if I want to use pv to add q value? The $var and $avp just have string and integer type. Thanks a lot!

1 0

My new blog http://cciev.ciscovoicetech.com/
by Arun Kumar 20 Feb '11

20 Feb '11

Hi Guys, Soon, I'll be starting a new section related to Asterisk (around 4 years of full time experience with Asterisk, Trixbox, SER, OpenSer, MediaProxy, AGI*) so let me know if you like to see some topic coming. Cheers Arun

1 0

Failure Route and Reply Routes
by Brandon Armstead 19 Feb '11

19 Feb '11

Hello, Is there any specific information / documentation as to what kind of response causes the failure_route to trigger over the reply_route. For example, it seems that 486 response triggers the failure route while as a 408 triggers the reply_route. Perhaps I am over looking something? I would imagine that 5xx and 6xx (final / non provisional responses) would trigger the failure route. While as 4xx would trigger the reply route -- however this does not always seem to be the case in the example of 486 vs 408. Any information / help in advance is greatly appreciated, thanks! Sincerely, Brandon Armstead

3 3

Kamailio NOTIFY
by Spinov Evgeniy 19 Feb '11

19 Feb '11

Hello all. I'm having problem with sending NOTIFY packet for event dialog. The problem is, that all NOTIFY packets sent with this event is empty. ( Content-length: 0 ) and in fact, not passing actual status to the phone. In my case this is SPA962. NOTIFY packets for event presence are sent fine and status is changing normally. The same phone, works fine with Asterisk. Asterisk is sending NOTIFY with non-zero content and changing status for the subscriber as well. I've turned on pua module to send PUBLISH requests at Kamailio, it's filling DB table with subscription, everything runs fine and NOTIFY packets are coming to subscribed phone, but they are empty. I also have presence_dialoginfo module on and pua_dialoginfo module on. I've tried on Kamailio 3.0.3 and 3.1.1. Content always empty. There is no sense of pasting here packet dumps, cause everything is like should be: (UAC) SUBSCRIBE, event: presence ---> K K ---> 202 OK (SPA) SUBSCRIBE, event: dialog ---> K K ---> 202 OK PUBLISH, event: presence ---> K K ---> 200 OK NOTIFY, event: presence, Content-Length: XXX ---> UAC NOTIFY, event: dialog, Content-Length: 0 ---> SPA962 As result, softphone changes status and hardphone ( SPA962 ) - no. May be it's cause of PUBLISH event value? Please advise.

2 10

why function result -1 cannot be assigned to variable?
by Juha Heinanen 19 Feb '11

19 Feb '11

i have a local function x that returns a positive integer or -1. when it returns -1, assignment $var(tmp) = function_x("$rd"); produces to syslog an error: Feb 19 07:32:44 sip /usr/sbin/sip-proxy[27284]: ERROR: <core> [lvalue.c:411]: assignment failed at pos: (1415,40-1415,40) i have had that function for years, but have not noticed these errors in earlier versions than 3.1. any ideas why the error is produced and how to get rid of it? -- juha

1 0

Interfaces guestures
by Spinov Evgeniy 18 Feb '11

18 Feb '11

Hello, all. I'm having Kamailio 3.0.4. Server have 2 physical interfaces, one is private, second is public. INVITE request is coming to Kamailio from public interface and being routed by Kamailio to one of ther asterisk boxes, which is in private network. Packet is routed to correct interface, but SRC address of packet, containing public Kamailio IP. As of that, asterisk is unable to communicate properly with Kamailio. I'm not applying any packet changes in Kamailio config and cannot get why Kamailio is doing that? Kamailio is listening both networks and able to send packets with correct IP, but somewhy sending an invalid one. Am I doing something wrong? Thank you.

2 1

Re: [SR-Users] pdb module timeouts
by Thomas Baumann 18 Feb '11

18 Feb '11

Hello Marius, thanks a lot for submitting the patch. It works like a charm now. But to be honest I had troubles to find this patch, I just checked the daily tarball [http://sip-router.org/tarballs/sr/] and found this change. How I can get patch e914f97b4 in a better way ? regards, Thomas >Hello >I have made a patch to 3.1(e914f97b4) . The poll() event list was not >cleared when a response was received so when 2 servers responded one >after the other it might block in an incorrect recv(). Can you please >test with this? >Marius ___________________________________________________________ Schon gehört? WEB.DE hat einen genialen Phishing-Filter in die Toolbar eingebaut! http://produkte.web.de/go/toolbar

4 4

Re: [SR-Users] ERROR: failover functions used, but AVPs paraamters required are NULL
by Gary Chen 18 Feb '11

18 Feb '11

Never mind. I used wrong kamailio.cfg file. From: Daniel-Constantin Mierla [mailto:miconda@gmail.com] Sent: Thursday, February 17, 2011 8:51 AM To: Gary Chen Cc: sr-users(a)lists.sip-router.org Subject: Re: [SR-Users] ERROR: failover functions used, but AVPs paraamters required are NULL Hello, can you send all log messages printed by: kamailio -E -ddd Thanks, Daniel On 2/17/11 2:42 PM, Gary Chen wrote: kamailio version 3.1.2 I am trying to setup dispatcher to use its failover feature. Here is dispatcher part of configure file: loadmodule "dispatcher.so" modparam("dispatcher", "db_url", DBURL) modparam("dispatcher", "table_name", "dispatcher") modparam("dispatcher", "ds_ping_interval", 30) modparam("dispatcher", "ds_probing_threshhold", 10) modparam("dispatcher", "ds_ping_reply_codes", "class=2;class=4") modparam("dispatcher", "ds_probing_mode", 1) modparam("dispatcher", "ds_ping_from", "sip:lb1 <at> m-lab-ca805-sig.kd-lab.de") modparam("dispatcher", "dst_avp", "$avp(dsdst)") modparam("dispatcher", "grp_avp", "$avp(dsgrp)") modparam("dispatcher", "cnt_avp", "$avp(dscnt)") modparam("dispatcher", "attrs_avp", "$avp(dsattrs)") modparam("dispatcher", "dstid_avp", "$avp(dsdstid)") modparam("dispatcher", "flags", 2) But it is still give the following error: 0(1917) ERROR: dispatcher [dispatcher.c:624]: failover functions used, but AVPs paraamters required are NULL -- feature disabled Does anybody know why? Gary _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- Daniel-Constantin Mierla http://www.asipto.com

2 1

Re: [SR-Users] Bad File Descriptor
by Daniel-Constantin Mierla 17 Feb '11

17 Feb '11

Please keep the mailing list cc-ed. My previous email had other comments/questions inline, can you answer them as well? They are relevant in troubleshooting. Thanks, Daniel On 2/17/11 7:57 PM, David J. wrote: > version: kamailio 3.1.1 (x86_64/linux) 88bda8 > flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, > USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, > SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, USE_FUTEX, > FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, > USE_DST_BLACKLIST, HAVE_RESOLV_RES > ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, > MAX_URI_SIZE 1024, BUF_SIZE 65535, PKG_SIZE 4MB > poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. > id: 88bda8 > compiled on 04:39:27 Dec 9 2010 with gcc 4.3.2 > > > > On 2/17/11 1:46 PM, Daniel-Constantin Mierla wrote: >> Hello, >> >> what is the version you are using? >> >> On 2/17/11 7:35 PM, David J. wrote: >>> 5(20390) ERROR: <core> [udp_server.c:586]: ERROR: udp_send: >>> sendto(sock,0x7f67f7f94d14,4,0,69.117.34.101:2048,16): Bad file >>> descriptor(9) >>> 5(20390) ERROR: nathelper [nathelper.c:1722]: udp_send failed >>> >>> >>> I see this error when I try to restart kamailio after crash; >> >> What is the cause for the crash? Do you have a log or core for that? >> >>> I see the cause of this problem is 'stale' entries in the location >>> table; >>> >>> If I delete this entries kamailio starts fine; any suggestions to >>> prevent this from continuously happening. >> Is any change in the IP address of the server upon restart? >> >> Do the errors persist or they stop after a while? They are related to >> NAT keepalives sent by nathelper module, so they don't affect the sip >> traffic and if they are for stale contacts then they are fully >> harmless. The stale contacts should be automatically removed after a >> while by usrloc module. >> >> Cheers, >> Daniel >> > -- Daniel-Constantin Mierla http://www.asipto.com

1 0

Bad File Descriptor
by David J. 17 Feb '11

17 Feb '11

5(20390) ERROR: <core> [udp_server.c:586]: ERROR: udp_send: sendto(sock,0x7f67f7f94d14,4,0,69.117.34.101:2048,16): Bad file descriptor(9) 5(20390) ERROR: nathelper [nathelper.c:1722]: udp_send failed I see this error when I try to restart kamailio after crash; I see the cause of this problem is 'stale' entries in the location table; If I delete this entries kamailio starts fine; any suggestions to prevent this from continuously happening. Thanks.

2 1

Kamailio 1.5.5 No TLS Segmentation Fault
by Stagg Shelton 17 Feb '11

17 Feb '11

Hello, We have been having a problem with Kamilio faulting and dumping core files on occasion. I have not been able to reproduce the failure at will, but notice the back trace seems to point toward actions with the dialogue. Below is from a backtrace of a core file from just a few minutes ago. Can anyone determine what may have caused the system to error and stop processing? Thanks Stagg Core was generated by `/sbin/kamailio -m 512'. Program terminated with signal 11, Segmentation fault. #0 0x00007f8a11d55fa7 in unref_dlg (dlg=0x7f89f7e07470, cnt=1) at dlg_hash.c:474 474 d_entry = &(d_table->entries[dlg->h_entry]); Missing separate debuginfos, use: debuginfo-install bzip2-libs-1.0.5-5.fc11.x86_64 db4-4.7.25-11.fc11.x86_64 e2fsprogs-libs-1.41.9-2.fc11.x86_64 elfutils-libelf-0.147-1.fc11.x86_64 glibc-2.10.2-1.x86_64 keyutils-libs-1.2-5.fc11.x86_64 krb5-libs-1.6.3-31.fc11.x86_64 libacl-2.2.49-3.fc11.x86_64 libattr-2.4.43-3.fc11.x86_64 libcap-2.16-4.fc11.1.x86_64 libconfuse-2.6-2.fc11.x86_64 libgcc-4.4.1-2.fc11.x86_64 libselinux-2.0.80-1.fc11.x86_64 lm_sensors-3.1.0-1.fc11.x86_64 lua-5.1.4-3.fc11.x86_64 mysql-libs-5.1.46-1.fc11.x86_64 net-snmp-libs-5.4.2.1-13.fc11.x86_64 nspr-devel-4.8.4-1.3.fc11.x86_64 nss-devel-3.12.6-1.2.fc11.x86_64 nss-softokn-freebl-3.12.6-1.2.fc11.x86_64 openssl-0.9.8n-1.fc11.x86_64 pcre-7.8-2.fc11.x86_64 perl-libs-5.10.0-82.fc11.x86_64 popt-1.13-5.fc11.x86_64 radiusclient-ng-0.5.6-4.fc11.x86_64 rpm-libs-4.7.2-1.fc11.x86_64 tcp_wrappers-libs-7.6-55.fc11.x86_64 xz-libs-4.999.9-0.1.beta.20091007git.fc11.x86_64 zlib-1.2.3-22.fc11.x86_64 (gdb) bt full #0 0x00007f8a11d55fa7 in unref_dlg (dlg=0x7f89f7e07470, cnt=1) at dlg_hash.c:474 d_entry = 0x0 __FUNCTION__ = "unref_dlg" #1 0x00007f8a11d5180f in unref_dlg_from_cb (t=0x7f89f7d9c660, type=4096, param=0x7f8a1836a6e0) at dlg_handlers.c:622 dlg = 0x7f89f7e07470 #2 0x00007f8a18138ea3 in run_trans_callbacks (type=4096, trans=0x7f89f7d9c660, req=0x0, rpl=0x0, code=0) at t_hooks.c:240 cbp = 0x7f89f7dc30e8 backup = 0x71a9d0 trans_backup = 0xffffffffffffffff __FUNCTION__ = "run_trans_callbacks" #3 0x00007f8a181273cc in free_cell (dead_cell=0x7f89f7d9c660) at h_table.c:132 b = 0x0 i = 1 rpl = 0x0 tt = 0x0 foo = 0x7fff4282f190 p = 0x7f89f7d3b068 #4 0x00007f8a18127bb6 in free_hash_table () at h_table.c:345 p_cell = 0x7f89f7d9c660 tmp_cell = 0x0 i = 4075 #5 0x00007f8a181342a4 in tm_shutdown () at t_funcs.c:109 __FUNCTION__ = "tm_shutdown" #6 0x00000000004529f6 in destroy_modules () at sr_module.c:321 t = 0x7349d0 foo = 0x734910 __FUNCTION__ = "destroy_modules" #7 0x000000000041f6b4 in cleanup (show_status=1) at main.c:331 No locals. #8 0x0000000000420597 in handle_sigs () at main.c:517 chld = 0 chld_status = 134 i = 12 do_exit = 1 ---Type <return> to continue, or q <return> to quit--- shutdown_time = 60 __FUNCTION__ = "handle_sigs" #9 0x00000000004217b5 in main_loop () at main.c:859 chd_rank = 12 i = 4 pid = 21442 si = 0x0 __FUNCTION__ = "main_loop" #10 0x0000000000423410 in main (argc=3, argv=0x7fff4282f498) at main.c:1321 cfg_log_stderr = 0 cfg_stream = 0x1fe1010 c = -1 r = 0 tmp_len = 0 port = 0 proto = 4910128 ret = -1 rfd = 4 tmp = 0x7fff4282ff8a "" options = 0x4b77e0 "f:cCm:b:l:n:N:rRvdDFETSVhw:t:u:g:P:G:W:" rand_source = 0x4b7d9c "/dev/urandom" seed = 3628387751 __FUNCTION__ = "main" (gdb) (gdb) quit

3 7

Failover with UCARP and Monit
by Hugh Waite 17 Feb '11

17 Feb '11

Hello, I am setting up a high-availablilty kamailio system using UCARP to failover between active and standby instances. To detect failure, we intend to use Monit. Monit can monitor the kamailio PID and start the process when needed (Example on the wiki http://www.kamailio.org/dokuwiki/doku.php/install:configure-initd-script) and it can also do OPTIONS pings to verify it is working. If the pings fail we will initiate a ucarp swap. However if the server is currently in standby, it does not have the V-IP address, so I don't want to run the OPTIONS pings (I think). Does anyone use a similar system and can provide an example of how ucarp, monit and kamailio can work together? Many thanks, Hugh Waite

4 5

Kamailio and Asterisk Realtime Integration using Asterisk Database
by Pavel Miskov 17 Feb '11

17 Feb '11

Hi all, I am trying to integrate Kamailio and Asterisk as explained in http://kb.asipto.com/asterisk:realtime:kamailio-3.0.x-asterisk-1.6.2-astdb document but I have some problems. 1. When Asterisk sends the call back to Kamailio, Asterisk generates new INVITE but with wrong From URI. In From header, "Display name" is OK (Phone A) but "From URI" is wrong (it is URI of Phone B). 2. When Phone B answers the call, Asterisk generates another INVITE to Phone B. When Phone B sends OK to this second INVITE Asterisk generates another INVITE to Phone A. 3. When Phone B sends BYE, Asterisk generates INVITE to Phone A and when it receives OK from Phone A it sends BYE to Phone A. I can fix the first problem with transformation in Kamailio but is this the way how it is supposed to work or I misconfigured something? I have tried this with kamailio 3.1 and asterisk 1.6.2.16.1 (and 1.8.2.3). Thanks Pavel

2 1

Mediaproxy 2.4.4 sessions
by Ricardo Martinez 17 Feb '11

17 Feb '11

Hello. I’m using kamailio 3.1.2 and mediaproxy 2.4.4 . Is there a way to see the active media sessions like in the old mediaproxy? I was using the command ./sessions Thanks Ricardo-.

2 1

Kamailio 3.0.4: Segfault at 4 [..] error 4 in dialog.so
by Klaus Feichtinger 17 Feb '11

17 Feb '11

Hello, does anybody have an idea, what this error messages could mean? Feb 16 11:23:27 SipSrvLstI1 kernel: [429767.707165] kamailio[10758]: segfault at 4 ip b78ba6e5 sp bfacece0 error 4 in dialog.so[b78a0000+32000] Feb 16 13:40:42 SipSrvLstI1 kernel: [438003.071797] kamailio[24880]: segfault at 4 ip b79416e5 sp bff7d460 error 4 in dialog.so[b7927000+32000] Feb 16 18:47:25 SipSrvLstI1 kernel: [456406.166885] kamailio[20939]: segfault at 4 ip b78d56e5 sp bfd821c0 error 4 in dialog.so[b78bb000+32000] I am setting the dialog flag for any incoming call..... Whenever a load test is running, this error occurs. I am not sure if it is reproduceable, or not. But I think it should be, because in worst case (during a load test over night) this error was indicated in a period of 1-2 minutes. But I've found this error only yesterday, because the server was down (as a result of this error....). The daemon (kamailio_3.0.4+lenny1_i386.deb) is running on a virtual machine (ESX) with OS Debian Lenny. How can I find / deliver additional info to this error / fault for analyzation? Thanks for any hints. Klaus

2 1

ACC og ACC_RADIUS module
by Morten Isaksen 17 Feb '11

17 Feb '11

Hi, We have a OpenSER 1.1 platform running with radius accounting and I am in the progress of updating it to Kamailio 3.1. I am trying to decide if I should do accounting via Radius or directly to MySQL on the new platform. The only benefits a can see with Radius is that you can build some redundancy into your radius client. If one Radius server is failing then try the next and you can configure radius to log to a file if the DB is down. But i think you can get the same level of redundancy with a replicated DB setup with heartbeat/pacemaker. If I choose to do the accounting direct to MySQL I will skip the Radius layer (and one error source). Are there any other pros and cons? -- Morten Isaksen

2 1

ERROR: failover functions used, but AVPs paraamters required are NULL
by Gary Chen 17 Feb '11

17 Feb '11

kamailio version 3.1.2 I am trying to setup dispatcher to use its failover feature. Here is dispatcher part of configure file: loadmodule "dispatcher.so" modparam("dispatcher", "db_url", DBURL) modparam("dispatcher", "table_name", "dispatcher") modparam("dispatcher", "ds_ping_interval", 30) modparam("dispatcher", "ds_probing_threshhold", 10) modparam("dispatcher", "ds_ping_reply_codes", "class=2;class=4") modparam("dispatcher", "ds_probing_mode", 1) modparam("dispatcher", "ds_ping_from", "sip:lb1 <at> m-lab-ca805-sig.kd-lab.de") modparam("dispatcher", "dst_avp", "$avp(dsdst)") modparam("dispatcher", "grp_avp", "$avp(dsgrp)") modparam("dispatcher", "cnt_avp", "$avp(dscnt)") modparam("dispatcher", "attrs_avp", "$avp(dsattrs)") modparam("dispatcher", "dstid_avp", "$avp(dsdstid)") modparam("dispatcher", "flags", 2) But it is still give the following error: 0(1917) ERROR: dispatcher [dispatcher.c:624]: failover functions used, but AVPs paraamters required are NULL -- feature disabled Does anybody know why? Gary

2 1

Re: [SR-Users] pdb module timeouts
by Thomas Baumann 16 Feb '11

16 Feb '11

2 1

Re: [SR-Users] Kamailio 1.5.4 and beyond - mhomed issue under Linux
by Sean O'Donnell 16 Feb '11

16 Feb '11

Hi Marius, Thanks for the reply. I found the patch in the 1.5 CVS branch. By the way, the 1.5.5 source tarball in /pub/kamailio/1.5.5/src was created before this patch was written, so the patch is not in there. The tarball I created from the 1.5 branch did have it. Thanks again, Sean O'Donnell Senior Engineer uReach Technologies, Inc. ---- On Mon, 14 Feb 2011, marius zbihlei (marius.zbihlei(a)1and1.ro) wrote: On 02/11/2011 09:14 PM, Sean O'Donnell wrote: > Hi all, > Hello Sean, > I checked the GIT repository and noticed that there was a patch in forward.c for > this issue. Looks like it was done 11/4/2010. Two questions: > > 1) Is there any reason that patch didn't make it into Kamailio 3.1.2 ? > Indeed, there is no reason. Actually I have cherry-picked the patches into the 3.1 branch (commit_notice 3.1 3ec1e9 and 9ef0a1e). Thanks for noticing. > 2) Any reason I shouldn't apply that patck to my 1.5.4 release? > The patch was already applied to the svn 1.5 branch (don't know if the latest 1.5.5 tar ball has it) but you can install it from svn and you can find it there (commit 6050) Cheers Marius > Thanks, > Sean O'Donnell > Senior Engineer > uReach Technologies, Inc. > > > > > > ---- On Thu, 10 Feb 2011, Sean O'Donnell (skodonnell(a)ureach.com) wrote: > > Hi all, > > I just started deploying Kamailio release 1.5.4, and I think there's an issue > with how Kamailio identifies an outgoing interface when mhomed is enabled under > Linux. > > I use Kamailio as a call distributor/proxy between a soft-switch/SBC and a > voicemail platform. It > runs on a CentOS 5.3 (Linux 2.6 kernel) host with two network interfaces and is > configured such that it listens on both interfaces. One interface (public > interface) handles traffic with the SBC, the other (private interface) handles > with the VM platform. The 'mhomed' option is enabled. > > After upgrading from 1.5.3 to 1.5.4, I started noticing problems with UDP > packets coming out of the public interface. After looking at some ngrep > captures on that interface, I noticed that some packets had the source IP > address of the private interface and also had Record-Route and Via headers for > the private interface only - no headers for the public interface were there. > > Usually when I see the wrong source IP in a UDP packet, it's an issue with how > routes are set up on the host. However, I had our network engineer double check > them, and they seem fine (no ambiguous routes). The fact that I captured these > messages on the public interface also indicates to me that the kernel is routing > the message correctly. The missing Record-Route and Via for the public > interface, however, lead me to believe that the proxy didn't correctly identify > the outgoing interface in the first place. > > After looking at the ChangeLog for 1.5.4, I noticed that the some new logic was > put in to improve performance when mhomed is enabled (r5971) in forward.c, and I > think this is the issue. > > As I understand it, prior to 1.5.4, when mhomed was enabled, Kamailio determined > the outgoing interface by creating a temporary UDP socket, invoking connect() on > the socket with the packet destination, then checking the source IP of the > socket that the kernel assigned using getsockname(). After the source address > was determined, the temp socket was closed closed. As of 1.5.4, this was > modified to reuse the temporary socket and just re-invoking connect() with a new > destination address. > > The problem with the enhancement is that Linux (again, at least in the 2.6 > kernels I'm using) > doesn't seem to rebind a new source address to the socket when connect() is > called more than once on > a UDP socket. Instead, it keeps the original one, and thus the wrong interface > is assumed. > > I wrote a small program to confirm this - basically creates a UDP socket, calls > connect()/getsockname() > multiple times using different destination addresses. I ran it on several 2.6 > kernels, including > Centos4.x and Centos5. The result was always that the source address of the > socket wasn't changed after the first connect(), regardless of the destination > address. The only way I could get it work as > required was to first do a connect() using a zero'd out AF_UNSPEC address before > doing the > connect() to the remote address. I also ran it on Solaris and it worked. Go > figure. > > I've downloaded the latest stable release (3.1.2) but I think the issue is still > there, and I don't see > anything in the user groups that addresses this. > > Any help would be appreciated. > > Thanks, > > Sean > > > _______________________________________________ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users(a)lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > > > > > _______________________________________________ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users(a)lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > > _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

2 1

Error when tring to load lcr module.
by Gary Chen 16 Feb '11

16 Feb '11

I am using Kamailio 3.1.2. I added lcr module in my kamailio.cfg file. After run this: ./kamctl -E I got this error: 0(23744) ERROR: lcr [lcr_mod.c:1235]: lcr_gw params at row <0> does not start with ';' 0 I have set up some gateway information in lcr_gw , lcr_rule and lcr_rule_target. From log it seems retrieve all the information but then got above error. Here is my lcr part of config: loadmodule "lcr.so" modparam("lcr", "db_url", DBURL) modparam("lcr", "gw_uri_avp", "$avp(i:709)") modparam("lcr", "ruri_user_avp", "$avp(i:500)") modparam("lcr", "flags_avp", "$avp(i:712)") Gary

2 1

Re: [SR-Users] pdb module timeouts
by Thomas Baumann 15 Feb '11

15 Feb '11

Hello, I did a fallback to the original source, without sucess. I still have massive timeouts. So far I have no idea, how to go on. ps. what lenght of the carrier codes would be ok ? 3...10 digits, additional characters needed like A,B,C,D,E,F? regards, Thomas Hi Henning, this change was done at pdbt.c: $ diff pdbt.c pdbt_changed.c 245c245 < bufsize = slen + 1 + 1 + 3 + 1 + 1; // line buff er (telephone number + colon + white space + carrier ID + newline + \0) --- > bufsize = slen + 1 + 1 + 4 + 1 + 1; // line buff er (telephone number + colon + white space + carrier ID + newline + \0) 257,258c257,258 < ret = snprintf(p, 5, "%d\n", node->carrier); < if (ret < 1 || ret > 4) { --- > ret = snprintf(p, 6, "%d\n", node->carrier); > if (ret < 1 || ret > 5) { If I run querys in filemode against the server, where is no timeout. pdbt query -f /tmp/numbers3 -r 10.12.18.21:10001 -q 1 | grep answer regards, Thomas -----Ursprüngliche Nachricht----- Von: "Henning Westerholt" <henning.westerholt(a)1und1.de> Gesendet: 11.02.2011 09:33:05 An: sr-users(a)lists.sip-router.org Betreff: Re: [SR-Users] pdb module timeouts On Wednesday 09 February 2011, Thomas Baumann wrote: > I am using the PDB module and server components for number portability. 2 > instances of PDB Server runs on (10.12.19.51/10001/10002), Kamailio on > (10.12.19.21). With a small amount of traffic (-cmax 150 -cps 10 > -callduration 3), where are timeouts: WARNING: pdb [pdb.c:260]: exceeded > timeout while waiting for response. > > One requested number was 307111094, where the module prints out a timeout. > > The funny part is, that I can see the responses at least arriving at the > 10.12.19.21 interface on time. > > Request send: 0,200855 s > Answer received: 0,201027 s > > That are 0,172 ms and far away from a timeout. > > What could be the reason ? Hi Thomas, a bit difficult to say on a first sight.. Maybe some scheduling or load issues on the local machine? I've just checked two production server here, i don't see it so far in the available logs. How much load do you've on the machine? And what kind of timeout value do you specified? > ps. A small change on the server part was done: handle 4 digit carrier > codes. Ah, i see. I guess its not a big change? Regards, Henning ___________________________________________________________ Schon gehört? WEB.DE hat einen genialen Phishing-Filter in die Toolbar eingebaut! http://produkte.web.de/go/toolbar

2 1

CORE postgres module
by Bruno Bresciani 15 Feb '11

15 Feb '11

Hi, During my tests with kamailio 1.5.0 a core is generated when postgres is disconnected and I try register a user or make a call in kamailio. Analising the module postgres source code I notice that core is generated by the PQescapeStringConn located in db_postgres_val2str function. Someone know why this core is generated? Best Regards

2 2

Issue with avp
by Amit Nepal 14 Feb '11

14 Feb '11

Hi, I have been trying to load rpid while loading credentials. modparam("auth_db", "load_credentials", "$avp(i:123)=rpid") Now, I am trying to do a check in my routing logic. xlog("L_NOTICE","The avp is :$avp(i:123)"); (I dont get the value here either, i can't see the value when i do avp_print() if($avp(i:123)<5) { sl_send_reply("408","Message Here"); } I dont get the value of avp at that place. Any guidance please. -- Thank You Amit Nepal Systems Administrator Phoenix Internet Phone: 602-385-0731 602-234-0917#112 http://www.phoenixinternet.net

2 4

kamailio 1.5.5 crashes continue
by Andrew O. Zhukov 14 Feb '11

14 Feb '11

Core was generated by `/usr/local/sbin/kamailio -P /var/run/openser/openser.pid -m 32 -u openser -g op'. Program terminated with signal 6, Aborted. #0 0x00000039d8c30265 in raise () from /lib64/libc.so.6 (gdb) backtrace #0 0x00000039d8c30265 in raise () from /lib64/libc.so.6 #1 0x00000039d8c31d10 in abort () from /lib64/libc.so.6 #2 0x000000000046c397 in qm_debug_frag (qm=0x733c00, f=0x841420) at mem/q_malloc.c:137 #3 0x000000000046d99a in qm_free (qm=0x733c00, p=0x841450, file=0x4e4d30 "parser/digest/digest.c", func=0x4e4da0 "free_credentials", line=95) at mem/q_malloc.c:439 #4 0x0000000000495fac in free_credentials (_b=0x2b875404a130) at parser/digest/digest.c:95 #5 0x0000000000471a36 in clean_hdr_field (hf=0x2b875404a100) at parser/hf.c:116 #6 0x00002b8750ab78de in clean_msg_clone (msg=0x2b8754049130, min=0x2b8754049130, max=0x2b875404a748) at sip_msg.h:54 #7 0x00002b8750ab77b7 in run_trans_callbacks (type=2, trans=0x2b8754057ec0, req=0x2b8754049130, rpl=0x7c0eb8, code=200) at t_hooks.c:245 #8 0x00002b8750abe39d in t_reply_matching (p_msg=0x7c0eb8, p_branch=0x7fffbe5d11e8) at t_lookup.c:888 #9 0x00002b8750abe997 in t_check (p_msg=0x7c0eb8, param_branch=0x7fffbe5d11e8) at t_lookup.c:964 #10 0x00002b8750acd79b in reply_received (p_msg=0x7c0eb8) at t_reply.c:1395 #11 0x000000000041c6db in forward_reply (msg=0x7c0eb8) at forward.c:576 #12 0x000000000043ccf0 in receive_msg ( buf=0x712980 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP XXX.XX.XXX.13;branch=z9hG4bK8aa9.93e271f1.0;received=XXX.XX.XXX.13\r\nVia: SIP/2.0/UDP XXX.XX.XXX.236:5060;received=XXX.XX.XXX.236;branch=z9hG4bK37dacff3;rport=5060\r\nRec"..., len=576, rcv_info=0x7fffbe5d1340) at receive.c:212 #13 0x00000000004692e3 in udp_rcv_loop () at udp_server.c:449 #14 0x0000000000420ecb in main_loop () at main.c:774 #15 0x0000000000422e0f in main (argc=11, argv=0x7fffbe5d15c8) at main.c:1321 (gdb) q [root@ tmp]# openser -V version: kamailio 1.5.5-notls (x86_64/linux) flags: STATISTICS, EXTRA_DEBUG, USE_IPV6, USE_TCP, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, PKG_SIZE 4194304 poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. svnrevision: unknown @(#) $Id: main.c 5608 2009-02-13 16:48:17Z henningw $ main.c compiled on 09:42:37 Feb 10 2011 with gcc 4.1.2 Andrew.

2 3

kamailio and MySQL licensing question
by Siddhardha Garige 14 Feb '11

14 Feb '11

hello all, I have a question regarding MySQL licensing. We configured kamailio to work in edge proxy mode with drive-by registration to support our network architecture. One of our clients is interested in conducting some trails with us and we are setting up a test network at client's facility. As a part of this process we will be installing our custom kamailio on their servers with MySQL. We are not charging our client for kamailio and mysql implementation since they both are open source implementations. But we will be charging them for our time at clients facility. Are we violating any MySQL license policies by installing our custom kamailio with MySQL for our client? thanks Sid "May the light be with you." ______________________________________________ Siddhardha Garige www.luminepixels.com

2 1

Re: [SR-Users] Kamailio 1.5.4 and beyond - mhomed issue under Linux
by Sean O'Donnell 14 Feb '11

14 Feb '11

Hi all, I checked the GIT repository and noticed that there was a patch in forward.c for this issue. Looks like it was done 11/4/2010. Two questions: 1) Is there any reason that patch didn't make it into Kamailio 3.1.2 ? 2) Any reason I shouldn't apply that patck to my 1.5.4 release? Thanks, Sean O'Donnell Senior Engineer uReach Technologies, Inc. ---- On Thu, 10 Feb 2011, Sean O'Donnell (skodonnell(a)ureach.com) wrote: Hi all, I just started deploying Kamailio release 1.5.4, and I think there's an issue with how Kamailio identifies an outgoing interface when mhomed is enabled under Linux. I use Kamailio as a call distributor/proxy between a soft-switch/SBC and a voicemail platform. It runs on a CentOS 5.3 (Linux 2.6 kernel) host with two network interfaces and is configured such that it listens on both interfaces. One interface (public interface) handles traffic with the SBC, the other (private interface) handles with the VM platform. The 'mhomed' option is enabled. After upgrading from 1.5.3 to 1.5.4, I started noticing problems with UDP packets coming out of the public interface. After looking at some ngrep captures on that interface, I noticed that some packets had the source IP address of the private interface and also had Record-Route and Via headers for the private interface only - no headers for the public interface were there. Usually when I see the wrong source IP in a UDP packet, it's an issue with how routes are set up on the host. However, I had our network engineer double check them, and they seem fine (no ambiguous routes). The fact that I captured these messages on the public interface also indicates to me that the kernel is routing the message correctly. The missing Record-Route and Via for the public interface, however, lead me to believe that the proxy didn't correctly identify the outgoing interface in the first place. After looking at the ChangeLog for 1.5.4, I noticed that the some new logic was put in to improve performance when mhomed is enabled (r5971) in forward.c, and I think this is the issue. As I understand it, prior to 1.5.4, when mhomed was enabled, Kamailio determined the outgoing interface by creating a temporary UDP socket, invoking connect() on the socket with the packet destination, then checking the source IP of the socket that the kernel assigned using getsockname(). After the source address was determined, the temp socket was closed closed. As of 1.5.4, this was modified to reuse the temporary socket and just re-invoking connect() with a new destination address. The problem with the enhancement is that Linux (again, at least in the 2.6 kernels I'm using) doesn't seem to rebind a new source address to the socket when connect() is called more than once on a UDP socket. Instead, it keeps the original one, and thus the wrong interface is assumed. I wrote a small program to confirm this - basically creates a UDP socket, calls connect()/getsockname() multiple times using different destination addresses. I ran it on several 2.6 kernels, including Centos4.x and Centos5. The result was always that the source address of the socket wasn't changed after the first connect(), regardless of the destination address. The only way I could get it work as required was to first do a connect() using a zero'd out AF_UNSPEC address before doing the connect() to the remote address. I also ran it on Solaris and it worked. Go figure. I've downloaded the latest stable release (3.1.2) but I think the issue is still there, and I don't see anything in the user groups that addresses this. Any help would be appreciated. Thanks, Sean _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

2 1

Error running kamailio 3.1.0
by Lucas Alvarez 12 Feb '11

12 Feb '11

Hi, I have compiled kamailio 3.1.0 without any error and I having this error when running kamailio: ERROR: <core> [sr_module.c:523]: ERROR: load_module: could not open module </usr/local/lib/kamailio/modules_k/sl.so>: /usr/local/lib/kamailio/modules_k/sl.so: undefined symbol: fm_malloc Any will be appreciated. Regards, Lucas

2 1

After upgrade from openser 1.3.4 to kamailio 1.5.5 the same crash set
by Andrew O. Zhukov 12 Feb '11

12 Feb '11

[root@ tmp]# /usr/local/sbin/kamailio -V version: kamailio 1.5.5-notls (x86_64/linux) flags: STATISTICS, EXTRA_DEBUG, USE_IPV6, USE_TCP, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, PKG_SIZE 4194304 poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. svnrevision: unknown @(#) $Id: main.c 5608 2009-02-13 16:48:17Z henningw $ main.c compiled on 12:38:36 Feb 2 2011 with gcc 4.1.2 ----------------------------- Core was generated by `/usr/local/sbin/kamailio -P /var/run/openser/openser.pid -m 32 -u openser -g op'. Program terminated with signal 11, Segmentation fault. #0 0x000000000046b0e3 in fm_malloc (qm=0x72dc00, size=32) at mem/f_malloc.c:354 354 if ((*f)->size>=size) goto found; (gdb) backtrace #0 0x000000000046b0e3 in fm_malloc (qm=0x72dc00, size=32) at mem/f_malloc.c:354 #1 0x00002b30f2803087 in build_rr (_l=0x76f110, _l2=0x76fe80, user=0x7fffe9c5a500, tag=0x777a58, params=0x0, _inbound=0) at record.c:176 #2 0x00002b30f2802b7a in record_route (_m=0x76e0e0, params=0x0) at record.c:322 #3 0x00002b30f28047db in w_record_route (msg=0x76e0e0, key=0x0, bar=0x0) at rr_mod.c:212 #4 0x000000000040ed9b in do_action (a=0x73f5a0, msg=0x76e0e0) at action.c:874 #5 0x000000000040c03a in run_action_list (a=0x73f5a0, msg=0x76e0e0) at action.c:145 #6 0x000000000040e6a7 in do_action (a=0x73f810, msg=0x76e0e0) at action.c:746 #7 0x000000000040c03a in run_action_list (a=0x73e418, msg=0x76e0e0) at action.c:145 #8 0x000000000040c2a9 in run_actions (a=0x73e418, msg=0x76e0e0) at action.c:120 #9 0x000000000040c357 in run_top_route (a=0x73e418, msg=0x76e0e0) at action.c:195 #10 0x000000000043bda4 in receive_msg ( buf=0x70c980 "NOTIFY sip:XXXXXX.com SIP/2.0\r\nVia: SIP/2.0/UDP XX.XXX.101.68:5060;branch=z9hG4bK-6ee3865\r\nFrom: VTHome <sip:101650@XXXXXX.com>;tag=129d73a13db8ec7fo0\r\nTo: <sip:XXXXX.com>\r\nCall-ID: e3fd1da9-142a0a17"..., len=373, rcv_info=0x7fffe9c5ae90) at receive.c:175 #11 0x0000000000467eeb in udp_rcv_loop () at udp_server.c:449 #12 0x000000000042097b in main_loop () at main.c:774 #13 0x00000000004228b0 in main (argc=11, argv=0x7fffe9c5b118) at main.c:1321 (gdb) print size $1 = 32 (gdb) quit -------------------------------------------- Core was generated by `/usr/local/sbin/kamailio -P /var/run/openser/openser.pid -m 32 -u openser -g op'. Program terminated with signal 11, Segmentation fault. #0 0x000000000046bf7b in fm_status (qm=0x72dc00) at mem/f_malloc.c:609 609 size+=f->size,f=f->u.nxt_free,i++,j++){ (gdb) backtrace #0 0x000000000046bf7b in fm_status (qm=0x72dc00) at mem/f_malloc.c:609 #1 0x000000000041feb3 in sig_usr (signo=15) at main.c:563 #2 <signal handler called> #3 0x00000039d8cd4a51 in __recvfrom_nocancel () from /lib64/libc.so.6 #4 0x0000000000467bf4 in udp_rcv_loop () at udp_server.c:408 #5 0x000000000042097b in main_loop () at main.c:774 #6 0x00000000004228b0 in main (argc=11, argv=0x7fffe9c5b118) at main.c:1321 (gdb) print i $1 = 402 (gdb) print j $2 = 1 (gdb) print size $3 = 7234295468789601279 (gdb) print f $4 = (struct fm_frag *) 0x3738656435393838 (gdb) print f->size Cannot access memory at address 0x3738656435393838 ------------------------------------------------------------------- Andrew O. Zhukov

2 6

pdb module timeouts
by Thomas Baumann 11 Feb '11

11 Feb '11

Hello, I am using the PDB module and server components for number portability. 2 instances of PDB Server runs on (10.12.19.51/10001/10002), Kamailio on (10.12.19.21). With a small amount of traffic (-cmax 150 -cps 10 -callduration 3), where are timeouts: WARNING: pdb [pdb.c:260]: exceeded timeout while waiting for response. One requested number was 307111094, where the module prints out a timeout. The funny part is, that I can see the responses at least arriving at the 10.12.19.21 interface on time. Request send: 0,200855 s Answer received: 0,201027 s That are 0,172 ms and far away from a timeout. What could be the reason ? regards, Thomas ps. A small change on the server part was done: handle 4 digit carrier codes. level3_logs: Feb 9 17:19:42 node2 /openser/sbin/kamailio[21200]: DEBUG: pdb [pdb.c:201]: querying '307111094'... Feb 9 17:19:42 node2 /openser/sbin/kamailio[21200]: WARNING: pdb [pdb.c:260]: exceeded timeout while waiting for response. ___________________________________________________________ Schon gehört? WEB.DE hat einen genialen Phishing-Filter in die Toolbar eingebaut! http://produkte.web.de/go/toolbar

3 4

Change transport=tls within Contact Header
by Bernhard Suttner 11 Feb '11

11 Feb '11

Hi, is there a function to change the transport field within the Contact Header? t_relay does relay it to the UDP port of the PBX but the transport within the Contact Header is still set to TLS. Later, the PBX does try to establish a TLS connection. The idea is now, that kamailio does set the transport of the Contact Header to UDP. Another possible way would to be, that I use the re.subst method but maybe there is a special function for that. Thanks in advance. Best regards, Bernhard

2 1

NAT, TLS and location table
by Bernhard Suttner 11 Feb '11

11 Feb '11

Hi, I am using TLS and recognize the following problem: The TLS connection are build up successfully but the natping (natping_interval = 10) does not send small dummy packets to the phones. The phones are behind a firewall with NAT. Registered phones with NAT but UDP do work correctly. They are getting the natping every 10 seconds. After 120 seconds (should be the tcp_connection_timeout) kamailio does send a FIN to the TLS phone to close the TLS connection. Should I increase the tcp_connection_timeout to a value bigger than the registration timeout? I thought I do not need that, because of the natping_interval. Is it maybe better to use a SIP-Options Ping instead of the small dummy packets? I would prefer the dummy packets because they are much smaller. BTW: Kamailio 3.1.1 and snom360 with latest v8 firmware. Thanks in advance! Best regards, Bernhard

2 3

handle_new_connect ... Too many open files
by Efelin Novak 11 Feb '11

11 Feb '11

Hi, today during two hours kamailio made 2G of a syslog messages. This message was repeated for 10 000 000 times. /sbin/kamailio[24272]: ERROR: <core> [tcp_main.c:3959]: WARNING: handle_new_connect: error while accepting connection(24): Too many open files It was preceded by following error. /sbin/kamailio[24265]: ERROR: <core> [tcp_read.c:269]: error reading: Connection reset by peer (104) /sbin/kamailio[24265]: ERROR: <core> [tcp_read.c:882]: ERROR: tcp_read_req: error reading Finally it stopped without any given reason. I'm using kamailio 3.1.0 (i386/linux) 1e204f, callcontrol 2.0.11 and clustered mysql. Was this some kind of attack, bug, error, misconfiguration or what? Thank for answer, Efelin

2 1

TLS Support
by Bernhard Suttner 11 Feb '11

11 Feb '11

Hi, how could I compile the TLS module and only the TLS module - not the other sources. BTW: The documentation within the http://www.kamailio.org/docs/tls.html is not up-to-date. Thanks in advance. Best regards, Bernhard

2 2

Kamailio as a sip client
by Amit Nepal 11 Feb '11

11 Feb '11

Hi, Is it possible to have kamailio register to a different proxy and route calls through that proxy ? -- Thank You Amit Nepal Systems Administrator Phoenix Internet Phone: 602-385-0731 602-234-0917#112 http://www.phoenixinternet.net

3 3

Kamailio 1.5.4 and beyond - mhomed issue under Linux
by Sean O'Donnell 10 Feb '11

10 Feb '11

Hi all, I just started deploying Kamailio release 1.5.4, and I think there's an issue with how Kamailio identifies an outgoing interface when mhomed is enabled under Linux. I use Kamailio as a call distributor/proxy between a soft-switch/SBC and a voicemail platform. It runs on a CentOS 5.3 (Linux 2.6 kernel) host with two network interfaces and is configured such that it listens on both interfaces. One interface (public interface) handles traffic with the SBC, the other (private interface) handles with the VM platform. The 'mhomed' option is enabled. After upgrading from 1.5.3 to 1.5.4, I started noticing problems with UDP packets coming out of the public interface. After looking at some ngrep captures on that interface, I noticed that some packets had the source IP address of the private interface and also had Record-Route and Via headers for the private interface only - no headers for the public interface were there. Usually when I see the wrong source IP in a UDP packet, it's an issue with how routes are set up on the host. However, I had our network engineer double check them, and they seem fine (no ambiguous routes). The fact that I captured these messages on the public interface also indicates to me that the kernel is routing the message correctly. The missing Record-Route and Via for the public interface, however, lead me to believe that the proxy didn't correctly identify the outgoing interface in the first place. After looking at the ChangeLog for 1.5.4, I noticed that the some new logic was put in to improve performance when mhomed is enabled (r5971) in forward.c, and I think this is the issue. As I understand it, prior to 1.5.4, when mhomed was enabled, Kamailio determined the outgoing interface by creating a temporary UDP socket, invoking connect() on the socket with the packet destination, then checking the source IP of the socket that the kernel assigned using getsockname(). After the source address was determined, the temp socket was closed closed. As of 1.5.4, this was modified to reuse the temporary socket and just re-invoking connect() with a new destination address. The problem with the enhancement is that Linux (again, at least in the 2.6 kernels I'm using) doesn't seem to rebind a new source address to the socket when connect() is called more than once on a UDP socket. Instead, it keeps the original one, and thus the wrong interface is assumed. I wrote a small program to confirm this - basically creates a UDP socket, calls connect()/getsockname() multiple times using different destination addresses. I ran it on several 2.6 kernels, including Centos4.x and Centos5. The result was always that the source address of the socket wasn't changed after the first connect(), regardless of the destination address. The only way I could get it work as required was to first do a connect() using a zero'd out AF_UNSPEC address before doing the connect() to the remote address. I also ran it on Solaris and it worked. Go figure. I've downloaded the latest stable release (3.1.2) but I think the issue is still there, and I don't see anything in the user groups that addresses this. Any help would be appreciated. Thanks, Sean

1 0

Merging nathelper modules
by Ovidiu Sas 10 Feb '11

10 Feb '11

Hello all, The nathelper module in modules_k was split in two: - nathelper (dealing with signaling); - rtpproxy (dealing with rtpproxy protocol). I would like to move the rtpproxy module from "modules_k" into "modules" and remove rtpproxy functionality from nathelper (s). This will give to (s) and (k) users: - rtpproxy: a single module for dealing with rtpproxy servers; - nathelper: two variants for dealing with NAT signaling. Next step, will be to merge the two nathelper modules into a single one. Thoughts? Regards, Ovidiu Sas

2 2

nathelper-module and sdp offer in 200 OK
by Emil Kroymann 10 Feb '11

10 Feb '11

Hi, We recently had a problem with the nathelper module and rtpproxy in a scenario where the SDP offer is sent only in the 200 OK. We use sip-router 3.1 and rtp-proxy from git master. The sip-router configuration uses the rtpproxy_offer() and rtpproxy_answer() functions in appropriate places. The problem is, that the arguments sent to the rtpproxy, when the ACK with the sdp answer arrives, seems to be not in the order, that rtpproxy expects. On the 200 OK, the nathelper module sends callid, to-tag, from-tag to rtpproxy. On the ACK, the nathelper module sends callid, from-tag, to-tag (with different command prefixes, of course, but I cannot remember them atm). The version of rtpproxy that we are using seems to expect, that the order of arguments sent on the ACK request is the same as on the 200 OK. My question: are there any module parameters, to correct this behaviour? Regards, Emil -- Emil Kroymann VoIP Services Engineer Email: emil.kroymann(a)isaco.de Tel: +49-30-203899885 ISACO GmbH Kurfürstenstraße 79 10787 Berlin Germany Amtsgericht Charlottenburg, HRB 112464B Geschäftsführer: Daniel Frommherz

3 12

Use different certificate for different client with TLS
by Daniel GROTTI 09 Feb '11

09 Feb '11

Hi all, I would like to use kamailio 3.1 with TLS and verified also a client certificate. My tls.cfg file is as follow: --- tls.cfg ---- ..... ..... [server:MY_IP:5061] method = TLSv1 verify_certificate = yes require_certificate = yes private_key = default_key.pem certificate = default_cert.pem ca_list = default_ca.pem [client:default] verify_certificate = no require_certificate = no .... .... So I want to verify the client certificate, to do that I use "is_peer_verified()" function in kamailio.cfg. As tls.cfg shows, I have to send to my clients the CA certificate and the client certificate (default_cert.pem + default_key.pem - signing by the CAcert). This client certificate is unique for all clients. Everything works fine. But suppose I wanted to create a client certificate for client 1 (cert_1.crt), and a different client certificate for client 2 (cert_2.crt) and I want to configure kamailio to be able to verified this different certificates. Does it possible ? How can I configure the tls.cfg file to do that ? I try to do something like this: [server:MY_IP:5061] method = TLSv1 verify_certificate = yes require_certificate = yes private_key = default_key_1.pem certificate = default_cert_1.pem private_key = default_key_2.pem certificate = default_cert_2.pem ca_list = default_ca.pem But when kamailio restart it seems that it read only the last couple of row certifcate/private_key. Regards, Daniel G

2 1

[OpenSER-Users] uaCSTA support in openser
by Hugo Koblmueller 09 Feb '11

09 Feb '11

high.all! i'm wondering if there is any support of uaCSTA in openser (planned)? i'm just working on the integration of asterisk (*) environment to OCS 2007 environment, having openSER in the middle (mainly for TCP/UDP translation and smoothing out the protocol deficienes on both sides). in this setup the * having the openSER in front is talking to the OCS (and vice versa) via the OCS mediation server, which is moreorless sending standard SIP messages, which enables normal softphone (integration to *) of the office communicator. this configuration is already working... now i'm planning to go for the CTI integration, where there is no OCS mediation server in between OCS and openSER, doing the translation of SIP/CSTA to SIP. i'm thinking about using openSER for this task, that's why i'm looking for a CSTA module or perl programm, which is capable of this functionality. afaik for the CTI communication there isn't the full complexity of CSTA needed, just a subset mainly for call setup and call clearing. anyone having experience on this topic? thx & cheers -hugo Great Ideas for Small Devices Hugo Koblmueller Senior Staff Engineer Software Development COMNEON electronic technology GmbH & Co. OHG Freistaedter Strasse 400 4040 Linz Austria hugo.koblmueller(a)comneon.com tel: fax: mobile: Skype ID: +43 (5) 1777 - 15730 <http://www.plaxo.com/click_to_call?lang=en&src=jj_signature&To=%2B43+%285%2 9+1777+%2D+15730&Email=hugo(a)koblmueller.com> +43 (5) 1777 - 15810 +43 (676) 82051280 <http://www.plaxo.com/click_to_call?lang=en&src=jj_signature&To=%2B43+%28676 %29+82051280&Email=hugo(a)koblmueller.com> drhookson Want to always have my latest info? <https://www.plaxo.com/add_me?u=21475050628&src=client_sig_212_1_banner_join &invite=1&lang=en> Want a signature like <http://www.plaxo.com/signature?src=client_sig_212_1_banner_sig&lang=en> this?

7 13

Re: [SR-Users] module postgres SER
by Daniel-Constantin Mierla 09 Feb '11

09 Feb '11

please keep the mailing list cc-ed, sending private messages is not in the spirit of public mailing lists. Others may want to follow up the discussion now or later. Thanks, Daniel On 2/9/11 5:01 PM, Bruno Bresciani wrote: > Daniel, > > thanks for your reply, really ser-0.8.1.4 is too old but i need to > solve this problem on that version. My great doubt is Why the aug_free > function corrupt the url of database after some attemps to reconnect. > Well, I'll try to understand this question... > > Best Regards > > > 2011/2/9 Daniel-Constantin Mierla <miconda(a)gmail.com > <mailto:miconda@gmail.com>> > > Hello, > > > On 2/9/11 2:19 PM, Bruno Bresciani wrote: > > Hi, > > I've seen the problem in a postgres module (SER-0.8.1.4), if > the connection fails and module tries to reparse url it fails > as CON_SQLURL(_h) is corrupted by the function aug_free() > after some reconnect attempts . When the postgres database > back to work, some modules doesn't get reconnect because the > db_url is corrupted. Why this is happening? There are some > solution for this problem? > > ser 0.8.1.4 is soooo old and I cannot fully remember, but I think > postgres module had no reconnect functionality at all by that time. > > However, version 3.1.x of SER (as well as Kamailio flavour) has db > reconnect functionality for postgres. You can try it and report if > something is not working, it will be fixed in 3.x, but I think > nobody is still developing on 0.8.x to backport anything there. > > Cheers, > Daniel > > -- > Daniel-Constantin Mierla > http://www.asipto.com > > -- Daniel-Constantin Mierla http://www.asipto.com

1 0

problem with bye using rtpproxy
by Amit Nepal 09 Feb '11

09 Feb '11

I have been trying to figure this out While using kamailio and rtpproxy, the caller is not receiving the bye when callee hangs up but audio is two way and everything seems to be working fine, any one had this issue ? -- Thank You Amit Nepal Systems Administrator Phoenix Internet Phone: 602-385-0731 602-234-0917#112 http://www.phoenixinternet.net

2 1

Multiple call accounting from an IP
by Amit Nepal 09 Feb '11

09 Feb '11

Hi everyone, I am sure someone have been working with this scenario, how about accounting multiple calls from same account or ip address while using ip auth ? -- Thank You Amit Nepal Systems Administrator Phoenix Internet Phone: 602-385-0731 602-234-0917#112 http://www.phoenixinternet.net

2 1

fosdem 2011 presentation about p_usrloc
by Henning Westerholt 09 Feb '11

09 Feb '11

Hello, this year the FOSDEM developer conference was a again a really nice event, the first time with an own room dedicated completely to open source telephony solutions! If you're interested in our presentation about the new p_usrloc module and how to scale location services with Kamailio, you can find it at the usual place on our webserver: http://kamailio.org/events/2011-fosdem/p_usrloc.pdf Best regards, Henning

3 3

module postgres SER
by Bruno Bresciani 09 Feb '11

09 Feb '11

Hi, I've seen the problem in a postgres module (SER-0.8.1.4), if the connection fails and module tries to reparse url it fails as CON_SQLURL(_h) is corrupted by the function aug_free() after some reconnect attempts . When the postgres database back to work, some modules doesn't get reconnect because the db_url is corrupted. Why this is happening? There are some solution for this problem? Best Regard

2 1

Fosdem2011 presentation: SIP Web20 Lua
by Daniel-Constantin Mierla 09 Feb '11

09 Feb '11

Hello, the presentation I did during Fosdem in Brussels last weekend is available at: http://www.kamailio.org/events/2011-fosdem/dcm-sip-web-lua.pdf The focus was to show how to interact with Kamailio via HTTP and how Kamailio can interact with Web services via HTTP, using Lua to make it easier. There are slides for a demo config of sending asynchronous notifications to Twitter on missed calls (using modules app_lua, mqueue, sqlops and rtimer). Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

1 0

[Serusers] problem with SER not proxying messages
by Asuncion Merino Rodríguez 09 Feb '11

09 Feb '11

Hola, no he visto respuesta a este foro, por favor alguien podría dar alguna respuesta?

1 0

Kamailio v3.1.2 Released
by Daniel-Constantin Mierla 08 Feb '11

08 Feb '11

Hello, Kamailio SIP Server v3.1.2 stable release is out. This is a maintenance release of latest stable branch, 3.1, that includes fixes since release of v3.1.1. There is no change to database or configuration file required to upgrade to 3.1.2 from 3.1.0 or 3.1.1 versions, therefore it is strongly recommended to upgrade to v3.1.2. For more details about version 3.1.2, visit: http://www.kamailio.org/w/2011/02/kamailio-v3-1-2-released/ Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

1 0

Problem with LCR!
by Ricardo Martinez 08 Feb '11

08 Feb '11

Hello. We’re having critical issues with our LCR, we have the Kamailio version 1.5.2, several calls are arriving to our LCR and from some reason the next message appears in the log : Feb 6 12:01:55 /usr/local/sbin/kamailio[14185]: NOTICE:lcr:gw_set_state: trunk "xx.xx.xx.135:5060" from group: <2099> is OFFLINE! We can see this message repeated for every single gateway in the “gw” table from the LCR, after this happened, the LCR rounting process is blocked and no more calls are processed. Can someone help us with this problem? Thanks in advance, *Regards,* *Ricardo Martinez.-* * *

3 3

planning release of v3.1.2
by Daniel-Constantin Mierla 08 Feb '11

08 Feb '11

Hello, I think it is time to release v3.1.2, first date that comes in my mind is next Thursday if everyone feels it is enough time to take care of backporting any fix he/she did and it is not yet there. That will provide us a fresh release for the FOSDEM event. If not, then maybe the other week, Tuesday, so the participants at the Kamailio Devel training in Barcelona can practice on it. Soon after we should plan also a release for previous stable, branch 3.0. Anyone having other options? Thanks, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

1 1

Problem with load_gws()
by Amit Nepal 08 Feb '11

08 Feb '11

Hi, Below is my config and i am getting error , missing load module modparam("lcr","db_url",DBURL) modparam("lcr", "gw_uri_avp", "$avp(i:709)") modparam("lcr", "ruri_user_avp", "$avp(i:500)") modparam("lcr", "flags_avp", "$avp(i:712)") route[LCR] { if(!load_gws()){ xlog("yes"); }; This gives me error : loading modules under /usr/local/lib/kamailio/modules_k/:/usr/local/lib/kamailio 0(1265) : <core> [cfg.y:3412]: parse error in config file routes/route-lcr.cfg unknown command, missing loadmodule? for load_gws() ERROR: bad config file (1 errors) Any guidance please ? -- Thank You Amit Nepal Systems Administrator Phoenix Internet Phone: 602-385-0731 602-234-0917#112 http://www.phoenixinternet.net

3 4

Handling timers from an Avaya PBX (throwing 404s)
by Graham Wooden 08 Feb '11

08 Feb '11

Hi there, I turned up a few new sip trunk customers this past week, from which one of them was an Avaya system. The customer wasn¹t able to do a username/password auth, so I set them up as a permanent entry in the location table. I am running Kamailio 1.5.5. The issue is that I am throwing back a 404 to them when they do a timer event, as they are passing sip:Unknown@my.ip.addr. I don¹t have a user name Unknown, hence the 404. I noticed that with the timer events from other customer¹s PBXs, that they are passing sip:my.addr, from which I am giving back 200 OK. What is the best way to handle this? Just let it go or add a ³Unknown² user (I don¹t like the latter, really)? Calls to and from their system is fine, so right now it¹s just entries in my logs but I hate spending CPU cycles on stuff that isn¹t going to benefit anyone. I sent an email back to the customer to see if maybe he can resolve it on his end, but I am doubtful on getting it resolved on his end. Thanks, -graham

3 5

Proposal to extend acc/dialog modules in order to log CDRs
by Timo Reimann 07 Feb '11

07 Feb '11

Hi all, I'd like to bring forward a proposal for creating CDRs (Call Data Records) from Kamailio by means of extending both acc and dialog modules. Feedback is very welcome. So far, CDR generation requires post-processing of log entries created by the (transaction-based) acc module or some other means. Looking at OpenSIPS (which is already capable of producing CDRs), my idea is to copy the basic notion of tracking dialogs for to-be-accounted calls and log a proper CDR on termination. Creating basic CDRs including start time, end time, and call duration can be accomplished quite easily this way. Apart from this very minimum CDR content, however, one can think of a number of CDR fields that cannot be filled easily. For instance, caller identity isn't always contained in the From header (think of CLIR calls) but need to be determined from other headers depending on the type of call, possibly even involving a database lookup. That's why I'd like to provide a way to pass additional, CDR-specific data from the configuration file to the dialog structure associated with the call. When the dialog is about to terminate, the extended acc module would make sure that the added CDR data associated to the dialog is included in the CDR. This way, users may define CDR fields to their personal needs from the configuration file in a flexible manner. In order to accomplish this, the dialog module would need to be extended such that dialog-specific data may be stored for the duration of a dialog (which is not possible to this day AFAICS). A new setter function attached to the dialog interface (struct dlg_binds) could accept a simple key/value pair for storage purposes. Exporting this function to the configuration file and accompanying it with a corresponding getter function will ensure that dialog-specific data may be written and read generically. Thus, improvements to the dialog module may be leveraged not just for CDR-accounting purposes. Regarding the acc module, a couple of new features need to be implemented: First, the introduction of another module parameter called something like "cdr_fields" that comprises the set of key names designated for CDR inclusion. Hence, a line like modparam("acc", "cdr_fields", "caller, callee, foo, bar") would require Kamailio configurators to store dialog-specific values for the keys "caller", "callee", "foo", and "bar", respectively, during call processing. The values will be fed to the dialog structure employing the new dialog store function explained above. Second, when the acc module is in CDR mode, dialogs shall be tracked from creation to termination using dialog callbacks. On termination of a dialog, values from keys referenced in the "cdr_fields" parameter will be fetched from the terminating dialog structure and associated with the new, fresh CDR. Third, the CDR is persisted to either log file, database, or both. Note that my approach would not touch the existing acc module functionality: CDR mode is supposed to be working in addition to transaction-based accounting as people will likely want to keep transaction logs for debugging or similar needs. A flag would enable and disable CDR generation at will. I have not fully investigated re-usability possibilities but believe that acc's persistence functions may be taken advantage of by the new CDR-producing parts as well. That's it with regards to the basic mode of operation. I am also thinking of having a few other features, such as using a switch to set the call start time to the moment the ACK or OK is seen instead of the INVITE (because users shouldn't be billed for call setup times). Looking forward to seeing your feedback on this proposal. Cheers, --Timo

3 6

topoh, angle brackets and Contact URI params interpretation
by Andrew Pogrebennyk 07 Feb '11

07 Feb '11

I'm having an issue with topoh module in Kamailio 3.1.0. When Contact header is formed like this: Contact: 0991 <sip:192.168.0.107;line=sr-N6IAzBysz.tyz.D4M.VLOBMfOBFuWxvfMxV4> The other party responds properly. But when there is no angle brackets in Contact: Contact: sip:192.168.0.107;line=sr-N6IAzB3AWxyfz.stM.quOBFZMJZfWxj7W.y-MljAWBy* Really, many parsers implement "prefer shift to reduce" principle, which means if something can be interpreted in more enclosed expression, it will be interpreted this way and no as part of less enclosed expression so ;line is interpreted as header parameter but not URI parameter. RFC 3261 section 20 suggests that any URI parameters be contained within angle brackets: === The Contact, From, and To header fields contain a URI. If the URI contains a comma, question mark or semicolon, the URI MUST be enclosed in angle brackets (< and >). Any URI parameters are contained within these brackets. If the URI is not enclosed in angle brackets, any semicolon-delimited parameters are header-parameters, not URI parameters. === I think the topoh module should force the angle brackets. BTW it seems that parameter needs to be urlencoded, see rule 'other-param' in RFC 3261 section 25.1: other-param = pname [ "=" pvalue ] pname = 1*paramchar pvalue = 1*paramchar paramchar = param-unreserved / unreserved / escaped param-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$" No .-* characters are allowed in the paramchar. But at least that's not causing me any problems. -- Sincerely, Andrew Pogrebennyk

3 6

Compiling Just One Module
by Amit Nepal 07 Feb '11

07 Feb '11

Could someone guide me how to compile and install just one module with flavor set to kamailio ? -- Thank You Amit Nepal Systems Administrator Phoenix Internet Phone: 602-385-0731 602-234-0917#112 http://www.phoenixinternet.net

3 4

authentication is not working
by Danny Dias 06 Feb '11

06 Feb '11

Hello my friends, I'm trying to configure authentication on my Kamailio and is not working at all :( I've added the following to the script to make it work: (but it doesn't) ... loadmodule "auth.so" loadmodule "auth_db.so" ... modparam("usrloc", "db_url", "mysql://kamailio:kamailiorw@localhost/kamailio") modparam("auth_db", "calculate_ha1", yes) modparam("auth_db", "password_column", "password") modparam("auth_db", "db_url", "mysql://kamailio:kamailiorw@localhost/kamailio") modparam("auth_db", "load_credentials", "") ... if (!(method=="REGISTER") && from_uri==myself) /*no multidomain version*/ { if (!proxy_authorize("", "subscriber")) { proxy_challenge("", "0"); exit; } if (!db_check_from()) { sl_send_reply("403","Forbidden auth ID"); exit; } consume_credentials(); } ... if (is_method("REGISTER")) { # authenticate the REGISTER requests (uncomment to enable auth) if (!www_authorize("", "subscriber")) { www_challenge("", "0"); exit; } ## if (!db_check_to()) { sl_send_reply("403","Forbidden auth ID"); exit; } if (!save("location")) sl_reply_error(); exit; } But is not working at all...take a look: # U 2011/02/03 09:31:04.402891 172.30.140.22:48752 -> 172.30.140.8:5060 REGISTER sip:172.30.140.8 SIP/2.0 Via: SIP/2.0/UDP 172.30.140.22:48752 ;branch=z9hG4bK-d87543-9a54af22967ae417-1--d87543-;rport Max-Forwards: 70 Contact: <sip:1000@172.30.140.22:48752;rinstance=fcade2df86ce0ab8> To: "1000"<sip:1000@172.30.140.8 <sip%3A1000(a)172.30.140.8>> From: "1000"<sip:1000@172.30.140.8 <sip%3A1000(a)172.30.140.8>>;tag=cd3e2323 Call-ID: MmU0YjM1NThiNTg0ZjhiNGM4ODA4ZmU1YWFiYjBmNTc. CSeq: 1 REGISTER Expires: 3600 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO User-Agent: X-Lite release 1011s stamp 41150 Content-Length: 0 # U 2011/02/03 09:31:04.404039 172.30.140.8:5060 -> 172.30.140.22:48752 SIP/2.0 200 OK Via: SIP/2.0/UDP 172.30.140.22:48752 ;branch=z9hG4bK-d87543-9a54af22967ae417-1--d87543-;rport=48752 To: "1000"<sip:1000@172.30.140.8 <sip%3A1000(a)172.30.140.8> >;tag=c97b4d1cb1f3d0da549e06a8d482ef63.34dc From: "1000"<sip:1000@172.30.140.8 <sip%3A1000(a)172.30.140.8>>;tag=cd3e2323 Call-ID: MmU0YjM1NThiNTg0ZjhiNGM4ODA4ZmU1YWFiYjBmNTc. CSeq: 1 REGISTER Contact: <sip:1000@172.30.140.22:48752 ;rinstance=fcade2df86ce0ab8>;expires=3600 Content-Length: 0 Am i missing something in my configuration? Thanks in advance!!!

5 12

503 Server error response for REGISTER request (Asterisk v1.6.0.5)
by Vikram Ragukumar 04 Feb '11

04 Feb '11

Hello, I had posted this question earlier on asterisk-users, but didn't receive any reply, so I'm posting on sr-users in the hope that someone can provide guidance on how to debug this problem. Our setup involves a Sip softphone registering with a fresh install of Asterisk v1.6.0.5 through an outbound proxy (Kamailio v3.1.1). We observe that about 80% of the time, immediately after startup of the softphone, when the softphone sends a REGISTER message, Asterisk replies with a "503 Server error". However, subsequent REGISTER messages are replied to appropriately (with a 401 Unauthorized). There are very few devices (under 5) registered with Asterisk, so this is not an overload issue. Please find attached a SIP trace for device registration. - What might cause this behavior in Asterisk ? - Are there any config file parameters that require to be changed ? - Would it help to see any other specific logs, if so which ones ? Thanks and Regards, Vikram.

2 3

SIP Router 3.03 topoh
by dotnetdub 04 Feb '11

04 Feb '11

Hi All, Kamailio had just started to get SIP attacked and it looked like they were sending a bad header and Kamailio died.. Nov 20 19:48:51 sipproxy sip[3383]: INFO: <script>: [R-MAIN =>] Request method OPTIONS is to our domain (212.124.123.170) Nov 20 19:48:51 sipproxy sip[3378]: INFO: <script>: [ROUTE-1] Received registration from sip:1368250498@sipproxy (212.124.123.170) Nov 20 19:48:51 sipproxy sip[3378]: INFO: <script>: [ROUTE-1 !] Credentials invalid; issuing challenge Nov 20 19:48:51 sipproxy sip[3381]: INFO: <script>: [ROUTE-1] Received registration from sip:100@sipproxy (212.124.123.170) Nov 20 19:48:51 sipproxy sip[3381]: INFO: <script>: [ROUTE-1 !] Credentials invalid; issuing challenge Nov 20 19:48:51 sipproxy sip[3374]: INFO: <core> [parser/msg_parser.c:339]: ERROR: bad header field [CSeq: 1 REGISTER ACK] Nov 20 19:48:51 sipproxy kernel: [1033573.401446] kamailio[3374]: segfault at 18 ip b70070d9 sp bf916118 error 4 in topoh.so[b7004000+c000] Nov 20 19:48:51 sipproxy sip[3373]: INFO: <core> [parser/msg_parser.c:339]: ERROR: bad header field [CSeq: 1 REGISTER ACK] Nov 20 19:48:51 sipproxy kernel: [1033573.636774] kamailio[3373]: segfault at 18 ip b70070d9 sp bf916118 error 4 in topoh.so[b7004000+c000] Nov 20 19:48:51 sipproxy sip[3388]: INFO: <core> [parser/msg_parser.c:339]: ERROR: bad header field [CSeq: 1 REGISTER ACK] Nov 20 19:48:51 sipproxy kernel: [1033573.680305] kamailio[3388]: segfault at 18 ip b70070d9 sp bf916118 error 4 in topoh.so[b7004000+c000] Nov 20 19:48:51 sipproxy sip[3390]: INFO: <core> [parser/msg_parser.c:339]: ERROR: bad header field [CSeq: 1 REGISTER ACK] Nov 20 19:48:51 sipproxy kernel: [1033573.710444] kamailio[3390]: segfault at 18 ip b70070d9 sp bf916118 error 4 in topoh.so[b7004000+c000] Nov 20 19:48:51 sipproxy sip[3383]: INFO: <script>: [ROUTE-1] Received registration from sip:2478223614@sipproxy (212.124.123.170) Nov 20 19:48:51 sipproxy sip[3383]: INFO: <script>: [ROUTE-1 !] Credentials invalid; issuing challenge Nov 20 19:48:51 sipproxy sip[3378]: INFO: <core> [parser/msg_parser.c:339]: ERROR: bad header field [CSeq: 1 REGISTER ACK] Nov 20 19:48:51 sipproxy kernel: [1033573.753334] kamailio[3378]: segfault at 18 ip b70070d9 sp bf916118 error 4 in topoh.so[b7004000+c000] Nov 20 19:48:51 sipproxy sip[3379]: INFO: <script>: [ROUTE-1] Received registration from sip:noauth@sipproxy (212.124.123.170) Nov 20 19:48:51 sipproxy sip[3379]: INFO: <script>: [ROUTE-1 !] Credentials invalid; issuing challenge Nov 20 19:48:51 sipproxy sip[3375]: INFO: <core> [parser/msg_parser.c:339]: ERROR: bad header field [CSeq: 1 REGISTER ACK] Nov 20 19:48:51 sipproxy kernel: [1033573.768137] kamailio[3375]: segfault at 18 ip b70070d9 sp bf916118 error 4 in topoh.so[b7004000+c000] Nov 20 19:48:51 sipproxy sip[3383]: INFO: <core> [parser/msg_parser.c:339]: ERROR: bad header field [CSeq: 1 REGISTER ACK] Nov 20 19:48:51 sipproxy kernel: [1033573.775628] kamailio[3383]: segfault at 18 ip b70070d9 sp bf916118 error 4 in topoh.so[b7004000+c000] Nov 20 19:48:51 sipproxy sip[3386]: INFO: <core> [parser/msg_parser.c:339]: ERROR: bad header field [CSeq: 1 REGISTER ACK] Nov 20 19:48:51 sipproxy kernel: [1033573.790925] kamailio[3386]: segfault at 18 ip b70070d9 sp bf916118 error 4 in topoh.so[b7004000+c000] Nov 20 19:48:51 sipproxy sip[3379]: INFO: <core> [parser/msg_parser.c:339]: ERROR: bad header field [CSeq: 1 REGISTER ACK] Nov 20 19:48:51 sipproxy kernel: [1033573.798926] kamailio[3379]: segfault at 18 ip b70070d9 sp bf916118 error 4 in topoh.so[b7004000+c000] Nov 20 19:48:51 sipproxy sip[3381]: INFO: <core> [parser/msg_parser.c:339]: ERROR: bad header field [CSeq: 1 REGISTER ACK] Nov 20 19:48:51 sipproxy kernel: [1033573.815493] kamailio[3381]: segfault at 18 ip b70070d9 sp bf916118 error 4 in topoh.so[b7004000+c000] Nov 20 19:48:54 sipproxy sip[3344]: INFO: <core> [main.c:737]: INFO: terminating due to SIGCHLD Nov 20 19:48:54 sipproxy sip[3399]: INFO: <core> [main.c:788]: INFO: signal 15 received Nov 20 19:48:54 sipproxy sip[3396]: INFO: <core> [main.c:788]: INFO: signal 15 received Nov 20 19:48:54 sipproxy sip[3400]: INFO: <core> [main.c:788]: INFO: signal 15 received Nov 20 19:48:54 sipproxy sip[3392]: INFO: <core> [main.c:788]: INFO: signal 15 received Nov 20 19:48:54 sipproxy sip[3401]: INFO: <core> [main.c:788]: INFO: signal 15 received Nov 20 19:48:54 sipproxy sip[3394]: INFO: <core> [main.c:788]: INFO: signal 15 received Nov 20 19:48:54 sipproxy sip[3402]: INFO: <core> [main.c:788]: INFO: signal 15 received Thanks Brian

4 20

dispatcher - ds_mark_dst("i"); is inactive only few seconds
by Thomas Baumann 04 Feb '11

04 Feb '11

Dear sr-users, I use this straight forward dispatcher config. In the failure route I am calling this function: ds_mark_dst("i"); Also this action is logged: Feb 2 17:20:31 node5 /openser/sbin/kamailio[15945]: INFO: : FAIL_ONE:time [Wed Feb 2 17:20:31 2011] destination sip:10.12.19.31:5060 marked as inactive The gateway is inactive: [root@node5 ~]# kamctl 'fifo' ds_list URI:: sip:10.12.19.31:5060 flag=I priority=0 attrs=test1=123;test2=456 URI:: sip:10.12.19.21:5060 flag=A priority=0 attrs=test1=123;test2=456 Few seconds later the gateway is active again (there is still now response to SIP-OPTIONS) [root@node5 ~]# kamctl 'fifo' ds_list URI:: sip:10.12.19.31:5060 flag=A priority=0 attrs=test1=123;test2=456 URI:: sip:10.12.19.21:5060 flag=A priority=0 attrs=test1=123;test2=456 Does anybody have a idea why ? regards, Thomas DB: mysql> select * from dispatcher -> ; +----+-------+----------------------+-------+----------+---------------------+-------------+ | id | setid | destination | flags | priority | attrs | description | +----+-------+----------------------+-------+----------+---------------------+-------------+ | 1 | 1 | sip:10.12.19.21:5060 | 0 | 0 | test1=123;test2=456 | AS 1 | | 2 | 1 | sip:10.12.19.31:5060 | 0 | 0 | test1=123;test2=456 | AS 2 | +----+-------+----------------------+-------+----------+---------------------+-------------+ CONFIG: #!KAMAILIO ####### Defined Values ######### #!define WITH_MYSQL #!define WITH_IPAUTH # *** Value defines - IDs used later in config #!ifdef WITH_MYSQL # - database URL - used to connect to database server by modules such # as: auth_db, acc, usrloc, a.s.o. #!define DBURL "mysql://openser:openserrw@10.12.18.51/openser" #!endif debug=2 log_stderror=no memdbg=5 memlog=5 log_facility=LOG_LOCAL0 fork=yes children=4 /* uncomment the next line to disable TCP (default on) */ #disable_tcp=yes /* uncomment the next line to disable the auto discovery of local aliases based on reverse DNS on IPs (default on) */ auto_aliases=no /* add local domain aliases */ alias="m-lab-ca805-sig.kd-lab.de:5060" alias="m-lab-ca805-sig.kd-lab.de" alias="10.12.19.51" /* uncomment and configure the following line if you want Kamailio to bind on a specific interface/port/proto (default bind on all available) */ listen=udp:10.12.19.51:5060 listen=tcp:10.12.19.51:5060 /* port to listen to * - can be specified more than once if needed to listen on many ports */ port=5060 ####### Modules Section ######## # set paths to location of modules mpath="/usr/local/kamailio-3.1/lib/kamailio/modules_k/:/usr/local/kamailio-3.1/lib/kamailio/modules/" # ------------------ module loading ---------------------------------- loadmodule "mi_fifo.so" loadmodule "kex.so" loadmodule "tm.so" loadmodule "tmx.so" loadmodule "sl.so" loadmodule "rr.so" loadmodule "pv.so" loadmodule "maxfwd.so" loadmodule "textops.so" loadmodule "siputils.so" loadmodule "xlog.so" loadmodule "sanity.so" loadmodule "ctl.so" loadmodule "mi_rpc.so" loadmodule "acc.so" loadmodule "dialplan.so" loadmodule "avpops.so" loadmodule "dispatcher.so" #!ifdef WITH_IPAUTH loadmodule "permissions.so" #!endif #!ifdef WITH_MYSQL loadmodule "db_mysql.so" #!endif # ----------------- setting module-specific parameters --------------- # ----- tm params ----- # auto-discard branches from previous serial forking leg modparam("tm", "failure_reply_mode", 3) # default retransmission timeout: 30sec modparam("tm", "fr_timer", 30000) # default invite retransmission timeout after 1xx: 120sec modparam("tm", "fr_inv_timer", 120000) # ----- dispatcher params ----- #modparam("dispatcher", "list_file", "/openser/etc/kamailio/dispatcher.list") modparam("dispatcher", "db_url", DBURL) modparam("dispatcher", "table_name", "dispatcher") modparam("dispatcher", "ds_ping_interval", 30) modparam("dispatcher", "ds_probing_threshhold", 10) modparam("dispatcher", "ds_ping_reply_codes", "class=2;class=4") modparam("dispatcher", "ds_probing_mode", 1) modparam("dispatcher", "ds_ping_from", "sip:lb1@m-lab-ca805-sig.kd-lab.de") modparam("dispatcher", "flags", 2) modparam("dispatcher", "dst_avp", "$avp(dsdst)") modparam("dispatcher", "grp_avp", "$avp(dsgrp)") modparam("dispatcher", "cnt_avp", "$avp(dscnt)") modparam("dispatcher", "attrs_avp", "$avp(dsattrs)") # ----- mi_fifo params ----- modparam("mi_fifo", "fifo_name", "/tmp/kamailio_fifo") # ----- permissions params ----- #!ifdef WITH_IPAUTH modparam("permissions", "db_url", DBURL) modparam("permissions", "db_mode", 1) #!endif route{ if ( !mf_process_maxfwd_header("10") ) { sl_send_reply("483","To Many Hops"); drop(); }; #!ifdef WITH_IPAUTH if (!allow_source_address()) { sl_send_reply("403", "Forbidden"); exit; } #!endif # Send to application servers for number evaluation if ($rU=~"^0[1-9][0-9]{5,20}$") { ds_select_dst("1","0"); if (method=="INVITE") { t_on_failure("FAIL_ONE"); } t_relay(); exit(); } sl_send_reply("403", "Forbidden"); exit; } # Sample failure route failure_route[FAIL_ONE] { if (t_check_status("408")) { xlog("L_INFO", "FAIL_ONE:time [$Tf] destination $avp(dsdst) marked as inactive \n"); ds_mark_dst("i"); } exit; } ___________________________________________________________ NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren: http://produkte.web.de/go/webdefreephone

2 5

Reloading a module without restart
by Stagg Shelton 04 Feb '11

04 Feb '11

Is it possible to reload a module such as siptrace without requiring a full restart of kamailio. I have changed my db_url modparam for the siptrace module and would like to avoid restarting kamailio if possible. Thanks Stagg

3 3

Problem with ser
by Asuncion Merino Rodriguez 02 Feb '11

02 Feb '11

Hello, i have insalled a ser server sucessfully. To try it, we was registered by a softphone, but when i am calling to the another registered user, he hang the phone but we cant ear anything. Can somebody help me? Thanks

1 0

Redundancy between 2 Kamailio servers
by Danny Dias 02 Feb '11

02 Feb '11

Hello my friends, I wonder if someone has done this before? i would like to implement 2 Kamailio servers with redundancy, something like the following: SERVER_A is working as the primary sip proxy (virtual IP as the sip signaling), if it fails, the other server (sleeping) should UP the virtual IP and takes all the traffic....i guess there is many Linux implementations thah can do this, but i would like to know if there is someone that has done this before and hear some recomendations... I've read some difficulty in the synchronisation of registrations because Kamailio works best when it stores registrations in memory and registrations are constantly changing - they expire and are renewed, as well as new ones joining and old ones leaving. To make the failover solution function seamlessly, it is necessary to synchronise the in-memory registrations between the primary and the backup server . This can be done by forking a copy of the registration request to the backup server, but there are some practical problems in doing this, has anyone do something with this? Thanks in advance!

6 21

Weird IPv6 Registration Issue
by Jon Farmer 02 Feb '11

02 Feb '11

Hi I am experimenting with a dual homed (IPv4 and IPv6) Openser 1.1.0-tls server. If I register using a IPv6 address then the initial registration works and the details are saved in the location table. However when the UA trys to re-register on expiry the SIP returns a 200 OK but the location data is not updated in the table. Looking at the syslog it is reporting that it didn't save the data as there was an existing entry on index with key 1. This is referring I presume to the primary index on "username, domain, contact) on the location table. So what happens is the first location entry expires and gets deleted from the table and thus there is no record for the subsequent register and thus openser thinks the UA has dropped off until the next re-register when because there is no longer a location record the data gets saved correctly. This doesn't happen if I register the same UA on IPv4 on the same openser server. Anyone got any ideas why this is happening? Regards Jon -- Jon Farmer Tel: 07795 118140 Email: viperdudeuk(a)gmail.com Twitter: @viperdudeuk

3 2

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