- sr-users - kamailio.org

nathelpler module path support
by Asgaroth 16 May '11

16 May '11

Hi All, I have a scenario where our registrar's are sitting behind our sip proxy. The sip proxy is the only system that has access to the outside world. Our registrar's are all on internal private addresses. I am trying to configure our registrar's to perform nat pinging. However, because the registrar's are on an internal address there is no way for the nat ping to get out. I enabled the path option so that the registrar stores the path that the registration comes in on. However it doesnt seem like the nathelper module uses the path parameter to send the outgoing nat ping. I tried the nat ping using sip method INFO, but the same applies, it does not appear to be able to send out via the outbound proxy. I tried to enable the natping option on the sip proxy, but it appears that only registrations with a socket address of the local host will get pinged, or else it is ignored. Is there an option that I am missing for the nat helper module that will enable me to set an outbound proxy for the nat ping messages? Any insight would be appreciated. Thanks

3 6

LCR strip and tags (prefix) - Kamailio 3.1
by Alexandre Abreu 14 May '11

14 May '11

Hi, With this LCR release from Kamailio 3.1 the table 'lcr_gw' makes four fields unique: lcr_id, ip_addr, port and hostname. This table is also responsible for setting 'strip' and 'tag' parameters values for the gateways. What I am trying to accomplish is to use different strip and tag values for the SAME gateway based only on what was dialed by the user. In 1.5 LCR for example, if user dialed 444 or 555 and both prefix belongs to the same gateway, I could use gw-sip for 444 (with values strip 1 and prefix 22) and also gw-sip for 555 (with values strip 2 and prefix 33). While this duplicate data, it was possible to play with routes without touching the config file. I am looking for ideas on how to implement that on K3.1 without using ifs, strip and prefix tied (statically) in the script file. As far as I know, for every new lcr_id inserted, I will need a corresponding load_gws(new_lcr_id) in the script. Regards, Alexandre.

2 1

DBTEXT - authentication against text files
by Pavel Segeč 13 May '11

13 May '11

Hi, does anybody have some knowledge or experience with DBTEXT module? I'm searching for working DBTEXT files examples and config files examples... thanks palo

1 0

[OT] SIP presence and BLF testing tools
by Andrew Pogrebennyk 12 May '11

12 May '11

Is there any framework available to do functional and regression testing of SIP presence and BLF? Ideally I'm looking for a tool for asserting the signaling flow and contents of the XML body (state, version numbers etc), also I'd like to be able to extract the tags and call-id into variables so as to create INVITE with Replaces. Working with message body variables in sipp is a pain. I'm also familiar with SIPr, Net::SIP and a few others, but that doesn't look suitable for someone without much development experience. Spirent is a perhaps a little closer than others in implementing pickup scenario but awkward when you go beyond the default test scenarios. So I'm interested in any information, tips, suggestions, commercial tools etc. I'm asking here 'cause judging from the quality of their BLF&presence OpenSIPS and Kamailio got the testing process just right. -- Sincerely, Andrew Pogrebennyk

2 1

core dump
by Dominguez Jover, Ricardo 12 May '11

12 May '11

Hi everybody, We are having an uncontrolled crash in Kamailio 3.1: May 10 20:34:51 tip1 /usr/local/kamailio-3.1/sbin/kamailio[23366]: : <core> [pass_fd.c:293]: ERROR: receive_fd: EOF on 39 May 10 20:34:51 tip1 /usr/local/kamailio-3.1/sbin/kamailio[23327]: ALERT: <core> [main.c:741]: child process 23364 exited by a signal 11 May 10 20:34:51 tip1 /usr/local/kamailio-3.1/sbin/kamailio[23327]: ALERT: <core> [main.c:744]: core was not generated I've read in several posts I must generate the "Core Dump" to know what is happening. I'm trying to generate it in this way. "/etc/init.d/Kamailio" file: if test "$DUMP_CORE" = "yes" ; then 1. set proper ulimit ulimit -c unlimited directory for the core dump files COREDIR=/dumps/ [ -d $COREDIR ] || mkdir $COREDIR chmod 777 $COREDIR echo "$COREDIR/core.%e.sig%s.%p" > /proc/sys/kernel/core_pattern fi "/etc/default/Kamailio" file: DUMP_CORE=yes But the core is not yet generated. Then I've added -w option: OPTIONS="-P $PID_FILE -m $MEMORY -u $USER -g $GROUP -w /dumps/" But core still not generated In "kamailio.cfg" I´ve also added: disable_core_dump=no User running Kamailio is "kamailio" who has 777 permissions in /dumps/ directory. No way. Anyhelp would be appreciated. Cheers, Ricardo Domínguez

3 5

Monitor SIP Trunk Usage with MRTG
by JR Richardson 11 May '11

11 May '11

Hi All, So I'm still banging away at monitoring various SIP trunk capacity, the dialog module is working well for this purpose. I am running local server cron job scripts to pull data and put into local flat files for reference. My next step is to pull this data from a remote server and graph with MRTG (this is what I use for most other network monitoring). It looks like I can use the mi_xmlrpc module and remotely query the SIP Router with kamctl commands and parse the results into MRTG. I'm interested in hearing from others that may have already done this and would not mind sharing some scripts or from anyone that has an alternative method. Any guidance or affirmation that this is a good method that works would be helpful. On the MRTG server, I'm using perl scripts for a lot of my data pulling. I am using Kamailio 3.0. Thanks. JR -- JR Richardson Engineering for the Masses

2 3

Kamailio + RTP Proxy modification -- programmer needed
by Salauddin Rubel 11 May '11

11 May '11

Hi, We need a programmer who can modify SIP and RTP packets passing through Kamailio and RTP proxy. Interested programmer can contact with me. Thanks

3 3

Dialog Module Question inbound/outbound count
by JR Richardson 10 May '11

10 May '11

Hi All, Been playing around with the dialog module to help me keep track of SIP trunk utilization, trying to identify how many calls are active on each SIP trunk. My dialog count for inbound calls is 10 (correct) but my outbound calls are always double that and I'm not sure why. Here is a snip of my config: loadmodule "dialog.so" if($rU=~"^111") { dlg_manage(); dlg_setflag("4"); set_dlg_profile("inbound","trunk111"); route(PDT); exit; } PDT lookup for prefix then call is forwarded to dispatcher to route out to carrier through 'route[relay]' route[RELAY] { dlg_setflag("4"); set_dlg_profile("outbound","$rd"); if (!t_relay()) { sl_reply_error(); exit; } exit; } I setup 10 active calls and here are my results: test-sip-router2:~# kamctl fifo profile_get_size inbound profile:: name=inbound value= count=10 test-sip-router2:~# kamctl fifo profile_get_size outbound profile:: name=outbound value= count=20 Also 'kamctl fifo dlg_list' will list only 10 active dialogs. So my question is, why am I getting a 20 count for outbound and only 10 count for inbound? Thanks. JR -- JR Richardson Engineering for the Masses

2 2

t_reply MI Datagram Function
by Torge Szczepanek 10 May '11

10 May '11

Hi! In the Documentation of the TMX Module for the t_reply function there is given a list of Parameters as can be seen here: http://www.kamailio.org/docs/modules/3.1.x/modules_k/tmx.html#id2822345 The third parameter is a trans_id. I cannot find any references for this. Is it possible to send a query to the MI Datagram socket, to do a lookup of the trans_id for a given callid or is there any other solution to get this information through the MI datagram socket, to be able to execute t_reply? It seems that t_reply_callid is doing what I want to do, but currently not through the MI Datagram socket and not including a body or new headers. Greetings Torge

2 2

INSTALL file
by Claudio Furrer 10 May '11

10 May '11

Hello, Is this still applicable? See INSTALL file (line 669) 3.1) create MySQL tables for SER flavour - if you have a previously installed SER on your system, use /usr/sbin/ser_mysql.sh reinstall to convert your SER database into new structures - otherwise, if this is your very first installation, use /usr/sbin/ser_mysql.sh create to create SER database structures (you will be prompted for password of MySql "root" user) Because I did not found the *reinstall* option on sources.. Thanks, Claudio

2 1

Re: [SR-Users] SIP Trunk Usage Monitoring
by JR Richardson 10 May '11

10 May '11

> On 09.05.2011 22:44, JR Richardson wrote: > > Would there be any usage examples of dialog module? I'm not sure if I > > really need profiles and [values] and when to set and unset. A push > > in the right direction would be helpful. > > Hi, > here is an example I've used for incoming and outgoing calls tracking, > just tune it for your purposes: > > loadmodule "dialog.so" > modparam("dialog", "dlg_flag", 4) > modparam("dialog", "db_mode", 1) > modparam("dialog", "profiles_with_value", "carrierin;carrierout") > ... > create_dialog(); > if(is_from_gw()) > { > # Monitor number of incoming calls > get_profile_size("carrierin","$si","$avp(s:cnt)"); > xlog("L_INFO", "----- currently, the carrier $si has > $avp(s:cnt) active outgoing calls\n"); > set_dlg_profile("carrierin","$si"); > } else { > # Monitor number of outgoing calls > get_profile_size("carrierout","$rd","$avp(s:cnt)"); > xlog("L_INFO", "----- currently, the carrier $rd has > $avp(s:cnt) active outgoing calls\n"); > set_dlg_profile("carrierout","$rd"); > } > > -- > Sincerely, > Andrew Pogrebennyk Thanks Andrew, very nice example, this will definitely help. Have a great day. JR

1 0

Re: [SR-Users] Dialog Module Usage Question
by JR Richardson 10 May '11

10 May '11

> > The problem I am having specifically is for outbound calls flowing > > through a dispatcher, I want to separate calls into a profile for each > > SIP domain that I send calls to. I'm not sure how do accomplish this. > > I see in kamctl fifo dlg_list, there is 'caller_bind_addr:: > > udp:10.10.12.24:5060'. Is there a way to export that into a variable > > that I can use as the 'profile' for the dialog? > > The domain part of the request URI is stored in a pseudovariable > called $rd. I would just use that as your profile 'value'. > > -- > Alex Balashov - Principal Thanks Alex, after I walked away from it for a bit, that came to mind. Really appreciate the feedback. Thanks. JR

1 0

Re: [SR-Users] SIP Trunk Usage Monitoring
by JR Richardson 10 May '11

10 May '11

>> I recently interconnected to an upstream carrier using Kamailio 3.0, >> working fine. We have configure 2 SIP trunks for failover/redundnacy. >> I'm using dispatcher module to round robin calls to the carrier. I >> wanted to monitor trunk usage between us. I was reading in the devel >> 3.2 about some native monitoring in the new dispatcher module without >> the need to load the dialog module. >> >> Can I use the new module in version 3.0 or will I need to upgrade the >> core to 3.2? >> >> I typically will not use dev software in production, so can anyone >> suggest a light method of trunk usage monitoring for ver 3.0? I'm not >> opposed to using the dialog module, I'm just not familiar with it and >> not sure the best way to integrate it for usage tracking. I don't >> need to do billing or capture cdr's on the SIP-Routers so the simpler >> the better. > > Honestly, going the dialog module route is your easiest bet. > > -- > Alex Balashov - Principal Thanks Alex, Would there be any usage examples of dialog module? I'm not sure if I really need profiles and [values] and when to set and unset. A push in the right direction would be helpful. Thanks. JR -- JR Richardson Engineering for the Masses

2 1

Dialog Module Usage Question
by JR Richardson 10 May '11

10 May '11

Hi All, I'm trying to configure the dialog module with profiles for outbound calls to different Dispatcher domains. I can get the dialog module configured for inbound calls and pull statistics and separate calls into specific profiles, that part is working well. The problem I am having specifically is for outbound calls flowing through a dispatcher, I want to separate calls into a profile for each SIP domain that I send calls to. I'm not sure how do accomplish this. I see in kamctl fifo dlg_list, there is 'caller_bind_addr:: udp:10.10.12.24:5060'. Is there a way to export that into a variable that I can use as the 'profile' for the dialog? Thanks. JR -- JR Richardson Engineering for the Masses

2 2

Ser AVP
by Claudio Furrer 09 May '11

09 May '11

Hello all, Have this issue with my ser config. I try to load a fwdbusy value from db using the $fu class, but it's complaining.. config: ... if (avp_db_load("$fu", "s:fwdbusy")) { ... log: 0(20749) ERROR: <core> [pvapi.c:516]: error searching pvar "fu" 0(20749) ERROR: <core> [pvapi.c:720]: wrong char [u/117] in [$fu] at [2 (0)] 0(20749) ERROR: avpops [avpops.c:275]: bad param 1; expected : $pseudo-variable or int/str value What's wrong with that? Should it not considered as a ser avp? Not K one. Or that avp_db_load is an exlusively K function? Thank you, Claudio

2 2

Kamailio fails to register to a VoIP provider
by Pierpaolo Culurciello 09 May '11

09 May '11

Dear all, I'm trying to register Kamailio (version 3.1.3) to different VoIP provider but I always receive a 401 unauthorized even if I use valid credentials. I post below two different capture of the registration to the same VoIP provider using the same credentials (SIP domain 94.23.56.123, SIP auth username 1028), with a Blink softphone (successful) and with Kamailio 3.1.3 (denied). The public IP address of my Kamailio is anonymized with XXXXXXXX: ------ Blink softphone -------- REGISTER sip:94.23.56.123 SIP/2.0 Via: SIP/2.0/UDP 192.168.2.1:49186;rport;branch=z9hG4bKPjGtybPeuocgJbvOZlRNoWG3RPL0peCs31 Max-Forwards: 70 From: "ItaliADSL" <sip:1028@94.23.56.123>;tag=Tid9EUBxo3Bc5Eo0xzaMg82Vk8q7J57j To: "ItaliADSL" <sip:1028@94.23.56.123> Contact: <sip:alybrkhq@192.168.2.115:49186> Call-ID: cdr3Rr05eEs0voSSZ275zLxVF.Eo74mo CSeq: 1 REGISTER Expires: 600 User-Agent: Blink 0.22.2 (MacOSX) Content-Length: 0 SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 192.168.2.1:49186;branch=z9hG4bKPjGtybPeuocgJbvOZlRNoWG3RPL0peCs31;received=95.248.232.55;rport=49186 From: "ItaliADSL" <sip:1028@94.23.56.123>;tag=Tid9EUBxo3Bc5Eo0xzaMg82Vk8q7J57j To: "ItaliADSL" <sip:1028@94.23.56.123>;tag=as5a82d867 Call-ID: cdr3Rr05eEs0voSSZ275zLxVF.Eo74mo CSeq: 1 REGISTER User-Agent: MOR Softswitch Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO Supported: replaces WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="6afe07ca" Content-Length: 0 REGISTER sip:94.23.56.123 SIP/2.0 Via: SIP/2.0/UDP 192.168.2.1:49186;rport;branch=z9hG4bKPj.JA-9Zf0dpKV6v0JmKtOGSMhyNw5ep1w Max-Forwards: 70 From: "ItaliADSL" <sip:1028@94.23.56.123>;tag=Tid9EUBxo3Bc5Eo0xzaMg82Vk8q7J57j To: "ItaliADSL" <sip:1028@94.23.56.123> Contact: <sip:alybrkhq@192.168.2.115:49186> Call-ID: cdr3Rr05eEs0voSSZ275zLxVF.Eo74mo CSeq: 2 REGISTER Expires: 600 User-Agent: Blink 0.22.2 (MacOSX) Authorization: Digest username="1028", realm="asterisk", nonce="6afe07ca", uri="sip:94.23.56.123", response="f3489b3c8510f39bcf3d1fd96b8836fb", algorithm=MD5 Content-Length: 0 SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.2.1:49186;branch=z9hG4bKPj.JA-9Zf0dpKV6v0JmKtOGSMhyNw5ep1w;received=95.248.232.55;rport=49186 From: "ItaliADSL" <sip:1028@94.23.56.123>;tag=Tid9EUBxo3Bc5Eo0xzaMg82Vk8q7J57j To: "ItaliADSL" <sip:1028@94.23.56.123>;tag=as5a82d867 Call-ID: cdr3Rr05eEs0voSSZ275zLxVF.Eo74mo CSeq: 2 REGISTER User-Agent: MOR Softswitch Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO Supported: replaces Expires: 600 Contact: <sip:alybrkhq@192.168.2.115:49186>;expires=600 Date: Sun, 08 May 2011 20:16:58 GMT Content-Length: 0 ----------- Kamailio 3.1.3 ---------------- REGISTER sip:94.23.56.123 SIP/2.0 Via: SIP/2.0/UDP XXXXXXXXXXX;branch=z9hG4bK58b4.3ac3b834.0 To: sip:1028@94.23.56.123 From: sip:1028@94.23.56.123;tag=464474ecb420f5357c1361be147933f0-45fd CSeq: 10 REGISTER Call-ID: 6efffe60-27704@XXXXXXXXXXXX Content-Length: 0 User-Agent: kamailio (3.1.3 (i386/linux)) Contact: <sip:1028@XXXXXXXXXX> Expires: 360 SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP XXXXXXXXXX;branch=z9hG4bK58b4.3ac3b834.0;received=XXXXXXXXXX From: sip:1028@94.23.56.123;tag=464474ecb420f5357c1361be147933f0-45fd To: sip:1028@94.23.56.123;tag=as322a1728 Call-ID: 6efffe60-27704@XXXXXXXXXXX CSeq: 10 REGISTER User-Agent: MOR Softswitch Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO Supported: replaces WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="5f3ee3e8" Content-Length: 0 REGISTER sip:94.23.56.123 SIP/2.0 Via: SIP/2.0/UDP XXXXXXXXXX;branch=z9hG4bK7666.c1b2e93.0 To: sip:1028@94.23.56.123 From: sip:1028@94.23.56.123;tag=464474ecb420f5357c1361be147933f0-1f9c CSeq: 10 REGISTER Call-ID: 6efffe60-27697@XXXXXXXXXXX Content-Length: 0 User-Agent: kamailio (3.1.3 (i386/linux)) Contact: <sip:1028@XXXXXXXXXXX> Expires: 360 Authorization: Digest username="1028", realm="asterisk", nonce="5f3ee3e8", uri="sip:94.23.56.123", response="df6ebfa9b5870b8b912d1e3b53eedc62", algorithm=MD5 SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP XXXXXXXXX;branch=z9hG4bK7666.c1b2e93.0;received=XXXXXXXXX From: sip:1028@94.23.56.123;tag=464474ecb420f5357c1361be147933f0-1f9c To: sip:1028@94.23.56.123;tag=as529fc11d Call-ID: 6efffe60-27697@XXXXXXXXXX CSeq: 10 REGISTER User-Agent: MOR Softswitch Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO Supported: replaces WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="41f3fe77" Content-Length: 0 -------------------------------------- As you can see from the captures, Blink softphone successfully registrates with VoIP provider while Kamailio's request is rejected. I tried to analize the two flows of SIP messages but I didn't notice any difference between them so I can't understand why Kamailio is not able to register. Can anybody help me to solve this issue? greetings, Pierpaolo

2 1

Authenticate if receiving 401
by Eric Hiller 09 May '11

09 May '11

I want kamailio to authenticate itself to a host if it is sent a 401, just as that host is expected to authenticate if kamailio sends it one. I am not finding much in the online probably because I am not searching for the right terms. Does anyone have any experience in this? Thanks! -Eric

4 4

Kamailio BLF - NOT SIMPLE
by Lucas Alvarez 09 May '11

09 May '11

Hi, I've been trying to configure kamailio for enabling BLF for Aastra phones. Sincerely, it's been a nightmare, till now I'm not sure if I have to enable pua_dialoginfo or presence_dialoginfo module or both for handling dialog events. Besides that is not clear which changes should be made to the route configuration nor which parameters should be configured. I would appreciate if anyone can enlighten me or could point me to the right documentation page. Thanks in advance. Lucas Alvarez

2 1

Force RTPProxy
by Simone Felici 09 May '11

09 May '11

Hello to all! I need a little help with our ser installation (ser-2.0.0-rc1). Due some network restrictions, we need to force every call to pass trought rtpproxy. Could someone point me to the right place where to force it? Please an example based on our config would be really helpful, but in two scenarios: 1. ALL CALLS trought rtpproxy 2. ONLY CALLS from a given network trought rtpproxy We are in doubt on what choose between the two solutions. Having both examples could me help to implement the needs faster :) Thank's a lot for your help! Simon

2 5

rewriteuri and append_branch with variables
by alex pappas 07 May '11

07 May '11

Dear All, I'm trying the following and i get error: $var(new_uri) = "sip:" +$avp(s:term_prefix) +$rU +"@" +$avp(s:gw_address); rewriteuri=($var(new_uri)); OR append_branch($var(new_uri)); But it seems that it does not like the variable. The documentation says that rewriteuri get a string so i don't understand why does not work. Do you have any ideas on this ? Cheers Alex

3 4

SIP Trunk Usage Monitoring
by JR Richardson 06 May '11

06 May '11

Hi All, I recently interconnected to an upstream carrier using Kamailio 3.0, working fine. We have configure 2 SIP trunks for failover/redundnacy. I'm using dispatcher module to round robin calls to the carrier. I wanted to monitor trunk usage between us. I was reading in the devel 3.2 about some native monitoring in the new dispatcher module without the need to load the dialog module. Can I use the new module in version 3.0 or will I need to upgrade the core to 3.2? I typically will not use dev software in production, so can anyone suggest a light method of trunk usage monitoring for ver 3.0? I'm not opposed to using the dialog module, I'm just not familiar with it and not sure the best way to integrate it for usage tracking. I don't need to do billing or capture cdr's on the SIP-Routers so the simpler the better. Any guidance will be much appreciated. Thanks. JR -- JR Richardson Engineering for the Masses

2 1

t_check_status documentation
by Eric Hiller 06 May '11

06 May '11

One thing that really threw me this morning was the lack of t_check_status in the modules documentation. Apparently it is still there and works, just completely undocumented. Once I realized it was still there I just went back to the 1.5 docs and was good, but just thought I should point this out. -Eric

2 1

db_text issue
by Eric Hiller 06 May '11

06 May '11

I would like to use dbtext to store a list of whitelisted gateways, but each time I load it I get a core segmentation fault. Any ideas? Here is my gateways db file: key_name(str) key_type(int) value_type(int) key_value(str) gwip:1:0:a gwip:1:0:b gwip:1:0:c gwcount:0:1:3 And in my config: modparam("htable","htable","gateways=>size=4;dbtable=gateways;") modparam("htable","db_url","text:///usr/local/etc/kamailio") while( $var(i) < $sht(gateways=>gwcount) ){ if( $sht(gateways=>gwip[$var(i)]) == $si ){ setflag(gateway); xlog("ISFROMGW: request from IP $si matches $sht(gateways=>gwip[$var(i)]) ...\n"); } } Do you see anything wrong with this setup? -Eric

2 4

free tickets linuxtag
by Henning Westerholt 06 May '11

06 May '11

Hello, we've few free 4 day tickets for the LinuxTag next week in Berlin to share. If you like to receive one, just send me a short reply. More informations about our booth: http://www.kamailio.org/w/2011/04/kamailio-booth-at-linuxtag-2011/ Best regards, Henning

1 0

Force RTPProxy
by Simone Felici 06 May '11

06 May '11

Hello to all! I need a little help with our ser installation (ser-2.0.0-rc1). Due some network restrictions, we need to force every call to pass trought rtpproxy. Could someone point me to the right place where to force it? Please an example based on our config would be really helpful, but in two scenarios: 1. ALL CALLS trought rtpproxy 2. ONLY CALLS from a given network trought rtpproxy We are in doubt on what choose between the two solutions. Having both examples could me help to implement the needs faster :) Thank's a lot for your help! Simon

1 0

Calling t_on_reply in branch_route doesn't work in Kamailio 3.1 - did work in Kamailio 1.5
by Sebastian Damm 05 May '11

05 May '11

Hi, I'm currently migrating a Kamailio 1.5 installation to Kamailio 3.1.3, and I got all config changes merged, except this one: branch_route[1] { if ((isbflagset(4)) && (!isflagset(7))) { fix_nated_sdp("1"); if (has_body()) { force_rtp_proxy("R"); } else { setflag(5); } t_on_reply("2"); } } In Kamailio 1.5 this worked without problems. In Kamailio 3.1 I get the following error (line 1627 is the line with t_on_reply on it): hostname:~# /usr/sbin/kamailio -c -f /etc/kamailio/proxy/kamailio.cfg loading modules under /urs/lib/kamailio/modules/:/usr/lib/kamailio/modules_k:/usr/lib/kamailio/modules_s/ 0(13670) : <core> [cfg.y:3412]: parse error in config file /etc/kamailio/proxy/kamailio.cfg, line 1627, column 17: Command cannot be used in the block ERROR: bad config file (1 errors) hostname:~# In the Kamailio 1.5 documentation it was stated for every t_on_* function, where it could be called. For t_on_reply it said: This function can be used from REQUEST_ROUTE, BRANCH_ROUTE, ONREPLY_ROUTE and FAILURE_ROUTE. In the Kamailio 3.1 documentation those lines are missing. But I don't really see a reason, why t_on_reply shouldn't be called from branch route. We need it for every branch to possibly have different onreply_routes. Am I missing something? Thanks in advance for any hints. Best regards, Sebastian

3 6

Force RTPProxy
by Simone Felici 05 May '11

05 May '11

Hello to all! I need a little help with our ser installation (ser-2.0.0-rc1). Due some network restrictions, we need to force every call to pass trought rtpproxy. Could someone point me to the right place where to force it? Please an example based on our config would be really helpful, but in two scenarios: 1. ALL CALLS trought rtpproxy 2. ONLY CALLS from a given network trought rtpproxy We are in doubt on what choose between the two solutions. Having both examples could me help to implement the needs faster :) Thank's a lot for your help! Simon

1 0

Re: [SR-Users] Kamailio lib/srdb1/db_id.c handling of multiple database connections and race condition
by Robert Verspuy 05 May '11

05 May '11

Hi Torge, I think it's better to send your mail to the mailinglist, then more people can have a look at your problem. I'm not really familiar with the kamailio source code. Just started using Kamailio about 8 months back. I came across a problem with requesting information from a postgresql database and made a patch which 'works for me'. I'm not using siptrace. Maybe you can supply more logging (through the mailinglist) of the database communication. The mysql error "Duplicate entry '96193' for key 'PRIMARY'" is a bit weird. As I said, I don't know and don't use the msyql driver in kamailio, but normally I would expect that mysql itself would take care of generating a primary key for the record. So maybe your problem is in the mysql server and not kamailio. Maybe this page can help you: http://www.softwareprojects.com/resources/programming/t-how-to-fix-mysql-du… With kind regards, Robert Verspuy Op 05-05-11 13:19, Dr. Torge Szczepanek schreef: > Hi! > > First of all thanks for all of your work. I really appreciate and I am > glad that there is such a nice Opensource SIP Proxy available. > > In a current project I am heavily relying on SIP Traces stored to a > database and other sqlops, dialplan operations using database connections. > > It seems that there is a race condition with SQL Databases (Postgres > and also MySQL) due to thread insafety as described in: > > http://lists.sip-router.org/pipermail/sr-dev/2010-October/009689.html > > This is causing multiple errors. I guess that the following error is > also caused by this race condition (thread safety): > > /usr/sbin/kamailio[5646]: ERROR: <core> [db_query.c:179]: error while > submitting query > /usr/sbin/kamailio[5646]: ERROR: siptrace [siptrace.c:532]: error > storing trace > /usr/sbin/kamailio[5646]: ERROR: db_mysql [km_dbase.c:120]: driver > error on query: Duplicate entry '96193' for key 'PRIMARY' > > My Kamailo Version (3.1.2) is reporting duplicate database URLs using > a warning: > > /usr/sbin/kamailio[5613]: WARNING: <core> [db_id.c:281]: identical DB > URLs, but different DB connection pid [5613/5562] > /usr/sbin/kamailio[5618]: WARNING: <core> [db_id.c:281]: identical DB > URLs, but different DB connection pid [5618/5562] > /usr/sbin/kamailio[5616]: WARNING: <core> [db_id.c:281]: identical DB > URLs, but different DB connection pid [5616/5562] > /usr/sbin/kamailio[5600]: WARNING: <core> [db_id.c:281]: identical DB > URLs, but different DB connection pid [5600/5562] > /usr/sbin/kamailio[5617]: WARNING: <core> [db_id.c:281]: identical DB > URLs, but different DB connection pid [5617/5562] > > Git commit 9fb37a55e0b97a98b7d2d104a7692f18cb3f7df6 is turning this > into a debug message, which I think is a bad idea if the thread > insafety still exists. > > As far as I know every thread should use its own database handle, at > least when using the MySQL API. > > Is there a way to handle this correctly? Can you give me any clues on > which approach to take here? Since I need a solution for this I would > like to fix this issue at least for myself and of course giving the > change back. > > Greetings Torge > -- > Dr. Torge Szczepanek > > Cygnus Networks GmbH Tel: +49-228-9090987-0 > Adenauerallee 73 Fax: +49-228-9090987-70 > D-53113 Bonn EMail: > info(a)cygnusnetworks.de <mailto:info@cygnusnetworks.de> > Amtsgericht Bonn, HRB 15928 SIP: info(a)cygnusnetworks.de > <mailto:info@cygnusnetworks.de> > Geschaeftsfuehrer Dr. Torge Szczepanek http://www.cygnusnetworks.de/ > Steuernummer 205/5710/1347 USt-ID DE258507007 > -- *Exa-Omicron* Patroonsweg 10 3892 DB Zeewolde Tel.: 088-OMICRON (66 427 66) http://www.exa-omicron.nl

2 1

lcr module: strip and tag
by Alida - Danilo SMALDONE 05 May '11

05 May '11

Hello, I've some understanding problem on lcr module. I've this route route[LCR] { xlog("L_INFO", "ENTRO IN ROUTE LCR ********************************** \n"); if (!load_gws(1)) { sl_send_reply("503", "Unable to load gateways"); exit; } else { $var(i) = 0; while(is_avp_set("$(avp(i:709)[$var(i)])")) { xlog("L_INFO","loading gw_uri_avp[$var(i)]='$(avp(i:709)[$var(i)])'\n"); $var(i) = $var(i) + 1; avp_print(); }; if(is_avp_set("$avp(i:709)")) { xlog("L_INFO", "Trying gateway '$avp(i:709)'\n"); } else { xlog("L_INFO", "No More Gateways \n"); }; # try the first matched gateway if (next_gw()) { xlog("L_INFO","ruri_user_avp='$avp(i:500)'\n"); xlog("L_INFO","test ruri_avp_mod='$tu'\n"); #xlog("L_INFO","************************************************************ ****\n"); avp_print(); # Route to failure for failover #t_on_failure("2"); route(RELAY); } else { sl_send_reply("503","No available gateways"); exit; }; }; exit; } And this is what I get: Apr 27 15:44:44 localhost kamailio[7827]: INFO: <script>: ENTRO IN ROUTE LCR ********************************** Apr 27 15:44:44 localhost kamailio[7827]: INFO: <script>: loading gw_uri_avp[0]='1|1|3|774|1171521237|172.16.10.200|5060||1|0' Apr 27 15:44:44 localhost kamailio[7827]: INFO: avpops [avpops_impl.c:1328]: p=0xb60dc5b0, flags=0x0112 Apr 27 15:44:44 localhost kamailio[7827]: INFO: avpops [avpops_impl.c:1334]: id=<709> Apr 27 15:44:44 localhost kamailio[7827]: INFO: avpops [avpops_impl.c:1340]: val_str=<1|1|3|774|1171521237|172.16.10.200|5060||1|0 / 45> Apr 27 15:44:44 localhost kamailio[7827]: INFO: <script>: Trying gateway '1|1|3|774|1171521237|172.16.10.200|5060||1|0' Apr 27 15:44:44 localhost kamailio[7827]: INFO: <script>: ruri_user_avp='09711234567' Apr 27 15:44:44 localhost kamailio[7827]: INFO: <script>: test ruri_avp_mod='sip: 09711234567(a)voip.myproxy.it' Apr 27 15:44:44 localhost kamailio[7827]: INFO: avpops [avpops_impl.c:1328]: p=0xb60dc624, flags=0x0110 Apr 27 15:44:44 localhost kamailio[7827]: INFO: avpops [avpops_impl.c:1334]: id=<712> Apr 27 15:44:44 localhost kamailio[7827]: INFO: avpops [avpops_impl.c:1342]: val_int=<0> Apr 27 15:44:44 localhost kamailio[7827]: INFO: avpops [avpops_impl.c:1328]: p=0xb60dc5b0, flags=0x0112 Apr 27 15:44:44 localhost kamailio[7827]: INFO: avpops [avpops_impl.c:1334]: id=<500> Apr 27 15:44:44 localhost kamailio[7827]: INFO: avpops [avpops_impl.c:1340]: val_str=<09711234567 / 11> I expected that the lcr module strips 3 numbers from avp(i:500) and adds the prefix 774. Anyone can explane why it didn't works? The called number never changes in 77409711891234567. Any help will be appreciated. Thank you Danilo

3 17

Rtp Port Question
by Sungjin Park 04 May '11

04 May '11

Hello, I use your sip service well. But there is one problem occured. I use your sip service on my android system. The application is Csipsimple. On Wifi and 3G connection, your service is very good. your sip account did good work. even 3G network connection. Btw, On Mobile Wimax service, the signal was good. But the Voice could not be trasnsferred. I guess the problem is about rtp port. *I'd like to know the rtp port that IPTEL use*. I will request Korea Telecom about rtp port open. Korea Telecom is Korean mobile Wimax Provider. Thank you. Sungjin Park Seoul, Korea

2 1

Re: [SR-Users] ? about presence
by hb 04 May '11

04 May '11

Thank you for your attention. I use the soft phone "jitsi" as is told in guide file and configure it as the guide. And I have checked the guide twice. I think there have nothing different with the guide excepts the db I used. >From: Martin Pohan?en?k <pohancenik.martin(a)gmail.com> >Subject: Re: [SR-Users] ? about presence >To: "SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - > Users Mailing List" <sr-users(a)lists.sip-router.org> >Message-ID: <BANLkTi=5S3OHe2SEDDe8ry+X+2ZUd2LqRg(a)mail.gmail.com> >Content-Type: text/plain; charset="gb2312" > >What SIP client app are you using to test presence ? >Please try to post the client configuration, too. > >Also try to go through the entire config file from the guide and compare >what is different from your config file. That might give you a clue of what >is wrong > >2011/5/3 Bucur Marius <bucur_marius_ovidiu(a)yahoo.com> > >> Hello, >> >> If you disable "#!define WITH_PRECENCE" you will not use presence at all - >> so it is most probably that you don't want that. >> When you use db_fallback mode, the subscribers are only written to database >> once in a while (in your case every 20 seconds). >> Also, if the subscribers are not authorized, they will only be in the >> "watchers" table - not active_watchers. >> Can you check if there is something in the "watchers" table? >> Also, can you check your system and see if it works without the xcap >> server? >> >> modparam("presence_xml", "force_active", 1) >> #modparam("presence_xml", "integrated_xcap_server", 1) >> >> Cheers, >> Marius >> >> ------------------------------ >> *From:* hb <hhb.1988(a)163.com> >> *To:* sr-users(a)lists.sip-router.org >> *Sent:* Tue, May 3, 2011 11:44:16 AM >> *Subject:* [SR-Users] ? about presence >> >> Dear everyone: >> I use kamalio 3.1. >> I want to add the xcap_sever and presence modules into my >> kamailio. I followed the lists " >> http://cache.baidu.com/c?m=9d78d513d99a12f00bb6ca255001d7175b14d7226b8b8142…" >> step by step. The only difference is that i use the database postgresql. >> When i start the server, it worked well, but the softphone was not >> able to show the presence of the contacts. >> I tried many times and found that when i disable the sentence >> "#!define WITH_PRECENCE" in "kamailio.cfg", it can show the state of the >> contacts. However, when i check the database, there was nothing in "Active >> Watchers" and "Presentity" tables. >> I think there must have something wrong with the configure of >> presence. Any response will be appreciated. >> >> >> >> ps: the configuration of the presence in kamailio.cfg as follows(same as >> the Tutorial): >> >> #!ifdef WITH_PRESENCE >> loadmodule "presence.so" >> loadmodule "presence_xml.so" >> #!endif >> >> #!ifdef WITH_PRESENCE >> # ----- presence params ----- >> modparam("presence", "db_url", DBURL) >> modparam("presence", "fallback2db", 1) >> modparam("presence", "db_update_period", 20) >> >> # ----- presence_xml params ----- >> modparam("presence_xml", "db_url", DBURL) >> modparam("presence_xml", "force_active", 0) >> modparam("presence_xml", "integrated_xcap_server", 1) >> #!endif >> haibo huang >> >> >> >> ------------------------------ >> ??????2G????????????????????3?!<http://mail.163.com/html/110414_attachment/att1.htm> >> >> _______________________________________________ >> 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 >> >> >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20110503/8d425fb…> > >------------------------------ > >Message: 2 >Date: Tue, 3 May 2011 12:55:57 +0900 >From: Sungjin Park <parksj84(a)gmail.com> >Subject: [SR-Users] Rtp Port Question >To: serusers(a)iptel.org >Message-ID: <BANLkTimJwR5e_yM5SA67QjYzOj8s=tgAjQ(a)mail.gmail.com> >Content-Type: text/plain; charset="iso-8859-1" > >Hello, I use your sip service well. >But there is one problem occured. > >I use your sip service on my android system. >The application is Csipsimple. > >On Wifi and 3G connection, your service is very good. your sip account did >good work. even 3G network connection. >Btw, On Mobile Wimax service, the signal was good. But the Voice could not >be trasnsferred. > > >I guess the problem is about rtp port. >*I'd like to know the rtp port that IPTEL use*. I will request Korea Telecom >about rtp port open. >Korea Telecom is Korean mobile Wimax Provider. > >Thank you. > >Sungjin Park >Seoul, Korea >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20110503/34b8728…> > >------------------------------ > >Message: 3 >Date: Tue, 3 May 2011 12:21:22 -0300 (ART) >From: Claudio Furrer <elcaio(a)gmail.com> >Subject: [SR-Users] INSTALL file >To: "SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - > Users Mailing List" <sr-users(a)lists.sip-router.org> >Message-ID: <alpine.LNX.2.00.1105031219240.29861(a)askepios.local> >Content-Type: TEXT/PLAIN; charset=US-ASCII > >Hello, > >Is this still applicable? > >See INSTALL file (line 669) > >3.1) create MySQL tables for SER flavour > - if you have a previously installed SER on your system, use > /usr/sbin/ser_mysql.sh reinstall > to convert your SER database into new structures > - otherwise, if this is your very first installation, use > /usr/sbin/ser_mysql.sh create > to create SER database structures > (you will be prompted for password of MySql "root" user) > >Because I did not found the *reinstall* option on sources.. > >Thanks, >Claudio > > > >------------------------------ > >Message: 4 >Date: Tue, 3 May 2011 12:49:22 -0300 (ART) >From: Claudio Furrer <elcaio(a)gmail.com> >Subject: [SR-Users] INSTALL file >To: "SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - > Users Mailing List" <sr-users(a)lists.sip-router.org> >Message-ID: <alpine.LNX.2.00.1105031223590.29861(a)askepios.local> >Content-Type: TEXT/PLAIN; charset=US-ASCII > >Hello, > >Is this still applicable? > >See INSTALL file (line 669) > >3.1) create MySQL tables for SER flavour > - if you have a previously installed SER on your system, use > /usr/sbin/ser_mysql.sh reinstall > to convert your SER database into new structures > - otherwise, if this is your very first installation, use > /usr/sbin/ser_mysql.sh create > to create SER database structures > (you will be prompted for password of MySql "root" user) > >Because I did not found the *reinstall* option on sources.. > >Thanks, >Claudio > > > >------------------------------ > >Message: 5 >Date: Wed, 4 May 2011 17:18:17 +0800 (CST) >From: hb <hhb.1988(a)163.com> >Subject: [SR-Users] RE?RE? ? about presence >To: bucur_marius_ovidiu(a)yahoo.com >Cc: sr-users(a)lists.sip-router.org >Message-ID: <694e6d8c.1c32b.12fba4cfaed.Coremail.hhb.1988(a)163.com> >Content-Type: text/plain; charset="gbk" > >Dear?Bucur Marius? > Thank you for your help. > As you said the presence module does not work if I disable it's module. This time I used wireshark to get the packages. I found when I disable the presence module, one point send the "Notify" packages directly to the other, and there were no changes in the watchers table. And when I enable the module, I found it can create some lists in watchers. But at this time , I found there is nothing contents in packages like "Subscribe" and "Notify".What's more when one point change the state, it dose not send any packages to the server. > You said active_watchers will have something when the subscribe is authorised. What dose it mean? My server have not authorised the subscribe? But it can have a call with other subscribe. > Look foreword your help. > haibo huang >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20110504/3f6d4fb…> > >------------------------------ > >_______________________________________________ >sr-users mailing list >sr-users(a)lists.sip-router.org >http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > > >End of sr-users Digest, Vol 72, Issue 5 >***************************************

1 0

RE：RE： ? about presence
by hb 04 May '11

04 May '11

Dear：Bucur Marius： Thank you for your help. As you said the presence module does not work if I disable it's module. This time I used wireshark to get the packages. I found when I disable the presence module, one point send the "Notify" packages directly to the other, and there were no changes in the watchers table. And when I enable the module, I found it can create some lists in watchers. But at this time , I found there is nothing contents in packages like "Subscribe" and "Notify".What's more when one point change the state, it dose not send any packages to the server. You said active_watchers will have something when the subscribe is authorised. What dose it mean? My server have not authorised the subscribe? But it can have a call with other subscribe. Look foreword your help. haibo huang

1 0

INSTALL file
by Claudio Furrer 03 May '11

03 May '11

Hello, Is this still applicable? See INSTALL file (line 669) 3.1) create MySQL tables for SER flavour - if you have a previously installed SER on your system, use /usr/sbin/ser_mysql.sh reinstall to convert your SER database into new structures - otherwise, if this is your very first installation, use /usr/sbin/ser_mysql.sh create to create SER database structures (you will be prompted for password of MySql "root" user) Because I did not found the *reinstall* option on sources.. Thanks, Claudio

1 0

： about presence
by hb 03 May '11

03 May '11

Dear everyone: I use kamalio 3.1. I want to add the xcap_sever and presence modules into my kamailio. I followed the lists "http://cache.baidu.com/c?m=9d78d513d99a12f00bb6ca255001d7175b14d7226b8b8142…" step by step. The only difference is that i use the database postgresql. When i start the server, it worked well, but the softphone was not able to show the presence of the contacts. I tried many times and found that when i disable the sentence "#!define WITH_PRECENCE" in "kamailio.cfg", it can show the state of the contacts. However, when i check the database, there was nothing in "Active Watchers" and "Presentity" tables. I think there must have something wrong with the configure of presence. Any response will be appreciated. ps: the configuration of the presence in kamailio.cfg as follows(same as theTutorial): #!ifdef WITH_PRESENCE loadmodule "presence.so" loadmodule "presence_xml.so" #!endif #!ifdef WITH_PRESENCE # ----- presence params ----- modparam("presence", "db_url", DBURL) modparam("presence", "fallback2db", 1) modparam("presence", "db_update_period", 20) # ----- presence_xml params ----- modparam("presence_xml", "db_url", DBURL) modparam("presence_xml", "force_active", 0) modparam("presence_xml", "integrated_xcap_server", 1) #!endif haibo huang

3 2

Error compiling Kamailio with mi_xmlrpc
by Lucas Alvarez 02 May '11

02 May '11

Hi, I'm trying to compile kamailio with mi_xmlrpc, I've followed the instructions, first installing xmlrpc-c-0.9.1.0 and xmlrpc-c-dev-0.9.1.0 but the folder xmlrpc-c in /usr/include is not created, so kamailio couldn't be compiled. Then I've installed the latest version of xmlrpc-c-dev, in this case the folder xmlrpc-c with the headers was created but the module didn;t compile, this are the errors: Makefile:46: You are using an unsupported libxmlrpc-c3 version (1.16.34), compile at your own risk! CC (gcc) [M mi_xmlrpc.so] abyss_data.o abyss_data.c:218: error: expected ')' before '*' token abyss_data.c:235: error: expected ')' before '*' token abyss_data.c:248: error: expected ')' before '*' token abyss_data.c:286: error: expected ')' before '*' token abyss_data.c:298: error: expected ')' before '*' token abyss_data.c:311: error: expected ')' before '*' token abyss_data.c:325: error: expected ')' before '*' token abyss_data.c:331: error: expected ')' before '*' token make: *** [abyss_data.o] Error 1 I would appreciate if someone can point me through the right path. Thanks in advance. Lucas Alvarez

1 0

i want to setup a SIP proxy and i dont know where to start.
by Eliezer Croitoru 02 May '11

02 May '11

i have a main office and a branch office. the main office and the branch office connected via vpn connection the branch office is natted to the main office. so i want to put on the gateway machine a SIP proxy server to nat the sip connection and also to proxy all the connections to SIP uses of the office. means i have one asterisk machine on the main site and other SIP providers that in a case i want to use i can use them also without connecting to the main office. i dont need asterisk on the branch office. the gateway server is ubuntu 10.04 amd64 what i should use Kamailio or the openser on the ubuntu repos? for now the Kamailio is installed.(not working). another feature i want to add is to be able to make calls between SIP phones using this server such as berni(a)mydomain.com from outside the office and vise verse... to dial people at bob(a)otherdomain.com hope for little help Eliezer

2 2

Kamailio performance testing
by Martin Pohančeník 02 May '11

02 May '11

Hi I am trying to test performance of kamailio server. I have made some tests on old hardware, that was ok. I found that it can handle around 450 calls per second with authorization. CPU utilisation was up to 100%. That testing was OK, because server's CPU utilization was increasing. Now I want to do some test with new hardware and do some comparisons of those two hardware configurations. I have made some test but i found that it can handle up to 540 calls per second with authorization. But CPU utilisation was only around 8%. When I increased call rate server responded with 404 Not Here and 500 I am terribly busy messages. I think that it is because of that it is not capable of finding a user location that fast. Can i do something to increase the performacne of this server? I am using SIPp testing tool for generating calls. I have registered users manualy with kamctl ul add sipp sip:sipp@192.168.1.1:5060 command. I was using this tutorial: http://www.troubleshootingwiki.org/OpenSER#Stress_Test_The_SIP_Signaling. And also i made my own scenarios. Any suggestion would be usefull. Thanks.

1 0

New module ipops
by Iñaki Baz Castillo 02 May '11

02 May '11

Hi, I've commited a new module named 'ipops' which provides operations with IPv4 and IPv6: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=5940394… The README describes the module functions: http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=blob;f=modules/… The module has no dependecies on other siprouter modules or external libraries, so if it's ok for you it could be enabled by default. Cheers. -- Iñaki Baz Castillo <ibc(a)aliax.net>

3 3

SIP outbound
by Klaus Darilion 02 May '11

02 May '11

Hi! IIRC we recently had a discussion about SIP outbound [1] and the benefits of an implementation in Kamailio. Just playing around with a SIP client on an iphone I discovered a usecase. Whenever the iphone gets a new IP address (quite often as it often changes between WiFi and 3G) the client reREGISTERs with the new IP address (establishing a new TCP connection). This leads to lots of "broken" registrations and TCP connections [2]. By use of SIP outbound and re-registration using the same "reg-id" the proxy would be able to replace the old registration with the new registration. Further, if Kamailio would have a mapping from registrations to TCP connections it could also close the dead TCP connections. regards Klaus [1] http://tools.ietf.org/html/rfc5626 [2] I do not know if TCP keepalives (socket option) could detect broken TCP connections without making too much noise on the receiver side (activating the background application and draining battery)

4 4

Kamailio v3.1.3 in Action
by Andreas Granig 01 May '11

01 May '11

Hi all, If you want to see a full-blown Kamailio v3.1.3 based open-source VoIP system in action, check our latest sip:provider CE v2.2-rc1, which has been released today: http://www.sipwise.com/news/announcements/spce-v2_2rc1-release/ It leverages the capabilities of Kamailio to build a quite complex SIP routing engine using a SIP load-balancer and a SIP proxy/registrar, as well as SEMS acting as b2bua. On top of it, it provides provisioning and billing modules and admin and user web interfaces to form an out-of-the-box VoIP soft-switch. Feedback is very much appreciated. Andreas

1 0

uri_db table version
by Claudio Furrer 29 Apr '11

29 Apr '11

Hello, I've found that scripts/my_create.sql doesn't create the version table anymore (new 3.1 installation). It may be removed since many versions ago, sorry i don't know. Loading the modules/db_mysql and modules_k/uri_db, with a SER flavour compilation (and also a ser config file), it raises: 0(15262) DEBUG: db_mysql [km_my_con.c:94]: opening connection: mysql://xxxx:xxxx@localhost/srtest 0(15262) DEBUG: db_mysql [km_my_con.c:121]: connection type is Localhost via UNIX socket 0(15262) DEBUG: db_mysql [km_my_con.c:122]: protocol version is 10 0(15262) DEBUG: db_mysql [km_my_con.c:123]: server version is 5.1.51-log 0(15262) ERROR: db_mysql [km_dbase.c:120]: driver error on query: Table 'ser_new.version' doesn't exist 0(15262) ERROR: <core> [db_query.c:101]: error while submitting query 0(15262) ERROR: <core> [db.c:366]: error in db_query Should I create the version table manually or using an old script? Thank you. Regards, Claudio

3 5

Re: [SR-Users] How to get rid of this error message.
by Gary Chen 29 Apr '11

29 Apr '11

Thanks. This fixed error. Is $rc the same as $retcode ? Gary -----Original Message----- From: Daniel-Constantin Mierla [mailto:miconda@gmail.com] Sent: Friday, April 29, 2011 1:01 PM To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing List Cc: Gary Chen Subject: Re: [SR-Users] How to get rid of this error message. Hello, On 4/29/11 4:32 PM, Gary Chen wrote: > I am using prefix2domain("2") in PDT module like this: > $var(found) = prefix2domain("2"); > and I got this error: > ERROR: <core> [lvalue.c:411]: assignment failed at pos: > (701,56-701,56) Apparently when prefix2domain("2) returns an value to > $var(found), it does not like it. But it still work. > The $var(found) still contains the return value (-1) if no prefix > found. And all my configuration is working. It just generate a lot of > this kind of error in my log file. Am I doing something wrong? How can > I fix it? I will look at it, it might be that the -1 return code is usually associated with an error case. Meanwhile try to replace that line with the following: prefix2domain("2"); $var(found) = $rc; Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

2 1

How to get rid of this error message.
by Gary Chen 29 Apr '11

29 Apr '11

I am using prefix2domain("2") in PDT module like this: $var(found) = prefix2domain("2"); and I got this error: ERROR: <core> [lvalue.c:411]: assignment failed at pos: (701,56-701,56) Apparently when prefix2domain("2) returns an value to $var(found), it does not like it. But it still work. The $var(found) still contains the return value (-1) if no prefix found. And all my configuration is working. It just generate a lot of this kind of error in my log file. Am I doing something wrong? How can I fix it? Gary

3 2

Kamailio with RTPoxy
by alex pappas 29 Apr '11

29 Apr '11

Dear all, I have a Kamailio with RTPoxy configured. The purpose is to pass the RTP from this server. When I make calls behind NAT the RTProxy seems to be engaged but in traces I don't see any RTP. Is there anything wrong with the idea or I'm missing something in the configuration ? Thank you Alex

3 5

is $td.did avp a normal avp?
by Juha Heinanen 26 Apr '11

26 Apr '11

domain module sets $td.did at lookup_domain call. $td.did seems to be a normal avp, because i can print its value with xlog by referring to it as $avp(td.did). however, its value is gone at failure route, which makes me suspect that $td.did is not really a normal avp. in route block i have $avp(did) = $td.did; xlog("L_INFO", "at t_relay: <td/td.did> = <$avp(did)/$avp(td.did)>\n"); if (t_relay()) exit; branch route, onreply route, and failure route are set when the above t_relay() takes place. at the end of branch route block, i have xlog("L_INFO", "at end of contact branches: <did/td.did> = <$avp(did)/$avp(td.did)>\n"); and at the beginning of onreply route block: xlog("L_INFO", "at beginning of onreply: <did/td.did> = <$avp(did)/$avp(td.did)>\n"); and at the beginning of failure route block: xlog("L_INFO", "at beginning of contact failure: <did/td.did = <$avp(did)/$avp(td.did)>\n"); when i make a call, i get to syslog: Apr 22 15:53:27 sip /usr/sbin/sip-proxy[13706]: INFO: at t_relay: <td/td.did> = <test.fi/test.fi> Apr 22 15:53:27 sip /usr/sbin/sip-proxy[13706]: INFO: at end of contact branches: <did/td.did> = <test.fi/test.fi> Apr 22 15:53:27 sip /usr/sbin/sip-proxy[13708]: INFO: at beginning of onreply: <did/td.did> = <test.fi/<null>> Apr 22 15:53:27 sip /usr/sbin/sip-proxy[13705]: INFO: at beginning of contact failure: <did/td.did = <test.fi/<null>> why is it that $avp(did) value has been preserved from route/branch route block to onreply/failure blocks, but value of $avp(td.did) is not? i'll cc to jan in case he is not on this list. -- juha

4 12

call for participation: kamailio project at LinuxTag 2011
by Henning Westerholt 26 Apr '11

26 Apr '11

Hello, in about five weeks the kamailio project will (again) be present on the LinuxTag fair, "the most important place for Linux and open source software in Europe" - http://www.linuxtag.org/2011/en.html . If you are in Berlin during this time, plan to visit the LinuxTag or just like to help your favourite SIP server project - please consider supporting us in running our fair booth! Even showing up for one or two hours helps a lot. We need also support to properly present our project, like flyers, a banner, maybe some live demonstrations.. So even if you can't participate in person, there are other ways to help us! Please contact me per mail if you could help at the booth or have some ideas about our project presentation. The actual state of preparations can be found in our wiki: http://sip-router.org/wiki/meetings/berlin_2011 Cheers, Henning

1 1

Bug in LDAP module?
by Pan B. Christensen 26 Apr '11

26 Apr '11

Hello, We are using kamailio 1.5 and we have the following problem with ldap_search: A call comes in. If it is to a VOIP user, it will be routed to kamailio, and eventually go to the ldap lookup route: route[10] to look up the user. This is always successful (LDAP can connect). It will then look up user preferences (call forwarding etc.) from SQL in route[12] and route based on this result in route[13]. If the result is "CFU (call forward unconditional) = on", the URI is changed and route[10] (LDAP lookup) is called again. This is always successful (LDAP can connect). If the result is "CFB (call forward busy) = on" and the user is busy, the URI is changed and route[10] (LDAP lookup) is called again. This is also always successful (LDAP can connect). If the result is "CFNR (call forward no reply) = on", the timeout is changed and the call is delivered to the phone through route[14] (location) and route[15] (relay). If the user does not answer, the URI is changed in failure_route[1] and route[10] is called. For some unknown reason, ldap_search always fails in this scenario with the messages: "ldap_session not found", "couldn't get ldap session" and then "no LDAP entry found". Why? And why does this result in the -1 return code and not the -2 return code for ldap_search? The only differences I can think of is that the unsuccessful scenario comes from FAILURE_ROUTE instead of REQUEST_ROUTE, and that longer time has passed since the original invite. Here's a sample log: NOTE the three ERROR lines, the INFO line and the ROUTE 10 line. Dec 27 13:31:55 [3373]: INVITE received from sip:<CALLER>@<SBC_IP> <source IP: <SBC_IP>> to sip:<CALLEE>@<KAM_IP>: Dec 27 13:31:55 [3373]: ERROR:ldap:ldap_reconnect: [ldapprod]: LDAP reconnect successful Dec 27 13:31:55 [3373]: ROUTE 10: LDAP returned: UID = <UID>, voipSipPrimaryUri = <PRIMARY_URI>, voipExtensionUri = sip:<CALLEE>@<DOMAIN> Dec 27 13:31:55 [3373]: ROUTE 12: Effective user properties for UID <UID>: CFU: off <FORWARDTO>, CFB: off <FORWARDTO>, CFNR: on:25 <FORWARDTO>, CFNC: off <FORWARDTO>, VM: <CALLEE>, busy_level: 1, DBrows: 1 Dec 27 13:31:55 [3373]: -------------------- Calling sip:<CALLEE>@<DOMAIN> for 25 seconds. -------------------- Dec 27 13:31:55 [3373]: ROUTE 15: Sending 105 INVITE from sip:<CALLER>@<SBC_IP> to sip:<CALLEE>@<CALLEE_IP> (via <<null>>) Dec 27 13:31:55 [3383]: Response 100 Trying to Cseq 102 INVITE received from <PROTO>:<CALLEE_IP>:<PORT> Dec 27 13:31:55 [3385]: Response 180 Ringing to Cseq 102 INVITE received from <PROTO>:<CALLEE_IP>:<PORT> Dec 27 13:32:20 [3388]: FAILURE_ROUTE 1: Timeout for: 104 INVITE from <CALLER> -> <CALLEE> Dec 27 13:32:20 [3388]: -------------------- Forwarding on no reply to <FORWARDTO> -------------------- Dec 27 13:32:20 [3388]: ERROR:ldap:get_connected_ldap_session: [ldapprod]: ldap_session not found Dec 27 13:32:20 [3388]: ERROR:ldap:lds_search: [ldapprod]: couldn't get ldap session Dec 27 13:32:20 [3388]: INFO:ldap:ldap_search_impl: no LDAP entry found Dec 27 13:32:20 [3388]: ROUTE 11: Number lookup results for <FORWARDTO>: Node: VOIP. Dec 27 13:32:20 [3388]: CONFIG ERROR: VOIP number not found in LDAP. Hanging up. Dec 27 13:32:20 [3373]: Response 487 Request Cancelled to Cseq 102 INVITE received from <PROTO>:<CALLEE_IP>:<PORT> Here's the ldap config file: [ldapprod] ldap_server_url = "ldap://ldap.<DOMAIN>" ldap_network_timeout = 500 ldap_client_bind_timeout = 500 kamailio config snippets (in case you need them): # LDAP lookup for UID and primary URI route[10] { ... ldap_search("ldap://ldapprod/<DN>?uid,voipSipPrimaryUri,voipExtensionUri?one?(&(objectClass=voipAddress)(|(voipSipUri=sip:$rU@uio.no)(|(voipSipUri=$var(uri))(voipSipUri=$var(e164uri)))))"); if ($retcode < 1) { switch ($retcode) { case -1: # no LDAP entry found route(11); return(1); case -2: # internal error sl_send_reply("500", "Internal server error"); exit; } } ldap_result("uid/$avp(s:uid)"); $avp(s:exten) = null; if (!ldap_result("voipExtensionUri/$avp(s:exten)")) { xlog("L_INFO", "voipExtensionUri not found.\n"); } if (!ldap_result("voipSipPrimaryUri/$avp(s:p-uri)")) { xlog("L_WARN", "voipSipPrimaryUri not found.\n"); #exit here? } if (isflagset(1)) { xlog("L_INFO", "ROUTE 10: LDAP returned: UID = $avp(s:uid), voipSipPrimaryUri = $avp(s:p-uri), voipExtensionUri = $avp(s:exten)\n"); } if $avp(s:exten) != null { $ru=$avp(s:exten); } else { $ru=$avp(s:p-uri); } route(12); } } # Number lookup. Non-VoIP URI's go here. route[11] { ... } # Database lookup for call forwarding. route[12] { ... } # Call forwarding logic route[13] { if (is_method("INVITE")) { $avp(s:uio_timer_avp) = "300"; if ($avp(s:cfu_status) == "on") { # Forward immediately xlog("L_INFO", "-------------------- $rU forwarded unconditionally to $avp(s:cfu_number). --------------------\n"); $rU = $avp(s:cfu_number); route(10); } ... if ( $var(dlg_busy) >= $avp(s:busy_level) ) { if ($avp(s:cfb_status) == "on") { xlog("L_INFO", "-------------------- $rU has $var(dlg_busy) active calls. Treshold $avp(s:busy_level). Forwarding on busy to $avp(s:cfb_number) --------------------\n"); $rU = $avp(s:cfb_number); route(10); } ... else if ($avp(s:cfnr_status) == "on") { # Forward to phone with timeout then to $avp(s:cfnr_number). # t_set_fr($avp(s:cfnr_timeout) + "000"); # Recommended method in 3.1. Function does not exist in 1.5. Using old method (avp). $avp(s:uio_timer_avp) = $avp(s:cfnr_timeout); xlog("L_INFO", "-------------------- Calling $ru for $avp(s:uio_timer_avp) seconds. --------------------\n"); route(14); } ... } failure_route[1] { ... if $avp(s:cfnr_status) == "on" { if (isflagset(1)) { xlog("L_INFO", "FAILURE_ROUTE 1: Timeout for: $mi $rm from $fU -> $rU\n"); } revert_uri(); $rU = $avp(s:cfnr_number); xlog("L_INFO", "-------------------- Forwarding on no reply to $rU --------------------\n"); route(10); } ... } With kind regards, Pan

3 5

Kamailio stops responding after 10 days or so
by Morten Isaksen 26 Apr '11

26 Apr '11

Hi! Kamailio 3.0.3. I have a strange problem with one of our Kamailio servers. This one is used for routing (with carrierroute) and to send presence information (with pua module) Once every 10 day or so I get this error and then Kamailio stops responding to any SIP packets. Apr 6 08:05:48 sip-core-1 /usr/local/sbin/kamailio[9186]: WARNING: <script>: Failure route - M=INVITE RURI=sip:8615XXXX@178.XX.XX.XX F=sip:861XXXXX@188.120.93.114:1025 T=sip:86155XXXX@sip1.uni-tel.dk IP=178.XX.XX.XX ID=6de881ec07f9c6494ee589cf208da358(a)10.11.87.206 Apr 6 08:05:48 sip-core-1 /usr/local/sbin/kamailio[9186]: ERROR: carrierroute [cr_func.c:95]: cannot find AVP 'carrier' Apr 6 08:05:48 sip-core-1 /usr/local/sbin/kamailio[9186]: ERROR: carrierroute [cr_func.c:805]: invalid carrier id -1 Apr 6 08:05:48 sip-core-1 /usr/local/sbin/kamailio[9186]: ERROR: <script>: cr_next_domain failed Shared memory size is 128M and over halv is free just before the error. The server is in production and does handle debug>1 well, so I do not have much information in the log files. Private memory is the default size. Any ideas what it could be, or how to investegate further? I think my next steps would be to increase the private memory og to increase children=4 to children=8 -- Morten Isaksen

3 7

Command 'sercmd lcr.dump_rules' out of memory.
by Alexandre Abreu 26 Apr '11

26 Apr '11

Hello. When running 'sercmd lcr.reload' (without any errors) and then 'sercmd lcr.dump_rules' I've got the following message: ERROR: ctl [binrpc_run.c:510]: ERROR: binrprc: rpc_send: too many message chunks Then I increased the CTL module params 'binrpc_max_body_size' and ' binrpc_struct_max_body_size'. Re-run the command: ERROR: ctl [binrpc_run.c:908]: ERROR: binrpc: rpc_add: out of memory kamailio -V version: kamailio 3.1.3 (x86_64/linux) 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 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: compiled on 19:43:43 Apr 18 2011 with gcc 4.1.2 It doesn't matter if I increase the PKG_SIZE (> 8). The LCR tables are very small. lcr_rule - 445 lines lcr_rule_target - 445 lines lcr_gw - 7 lines Alexandre

2 1

Re: [SR-Users] Ipv6 SIP UA
by Klaus Darilion 26 Apr '11

26 Apr '11

You are right! There are actually 2 issues with pjsip: - UDP6 transport does not support DNS lookups. Thus you must set an outboundproxy with IPv6 address - pjsua API does not handle IPv6 media (SDP) As Qjsimple is based on pjsip's pjsua API QjSimple of course has the same issue. regards klaus Am 21.04.2011 14:05, schrieb Pavel Segeč: > Klaus, > > still the same, > > here is a log when UDP is used, there is only A record resolving > > QjSimple: starting initialization/registration ... > QjSimple: initializing SIP stack ... > QjSimple: pjsua_create succeeded ... > QjSimple: "qjsimple" memory pool created ... > QjSimple: DLL loaded ... > QjSimple: GetNetworkParams found ... > QjSimple: GetNetworkParams done ... > QjSimple: cfg.nameserver_count=0 > QjSimple: pjsua_init succeeded ... > QjSimple: pjsip_endpt_register_module succeeded ... > QjSimple: adding UDP transport ... > QjSimple: pjsip_endpt_register_module succeeded ... > QjSimple: outboundUri=sip:ps.sip.uniza.sk;lr;transport=udp > QjSimple: registration_enabled=TRUE > QjSimple: publish_enabled=FALSE > QjSimple: pjsua_acc_add succeeded ... > QjSimple: finished intializing SIP stack, start pjsua ... > QjSimple: Info: on_reg_state_slot called > QjSimple: Info: on_reg_state_slot: status=502 > QjSimple: Info: on_reg_state_slot: statustext=Bad Gateway > QjSimple: Info: on_reg_state_slot called > QjSimple: Info: on_reg_state_slot: status=502 > QjSimple: Info: on_reg_state_slot: statustext=Bad Gateway > > and here when UDP6 > > QjSimple: starting initialization/registration ... > QjSimple: initializing SIP stack ... > QjSimple: pjsua_create succeeded ... > QjSimple: "qjsimple" memory pool created ... > QjSimple: DLL loaded ... > QjSimple: GetNetworkParams found ... > QjSimple: GetNetworkParams done ... > QjSimple: cfg.nameserver_count=0 > QjSimple: pjsua_init succeeded ... > QjSimple: pjsip_endpt_register_module succeeded ... > QjSimple: adding UDP6 transport ... > QjSimple: pjsip_endpt_register_module succeeded ... > QjSimple: outboundUri=sip:ps.sip.uniza.sk;lr;transport=udp > QjSimple: registration_enabled=TRUE > QjSimple: publish_enabled=FALSE > QjSimple: pjsua_acc_add succeeded ... > QjSimple: finished intializing SIP stack, start pjsua ... > > there is no DNS at all > > pavel > > >> -----Original Message----- >> From: sr-users-bounces(a)lists.sip-router.org [mailto:sr-users- >> bounces(a)lists.sip-router.org] On Behalf Of Klaus Darilion >> Sent: Thursday, April 21, 2011 1:27 PM >> To: sr-users(a)lists.sip-router.org >> Subject: Re: [SR-Users] Ipv6 SIP UA >> >> Pavel, I have updated QjSimple to latest pjsip version (0.8.10). It >> would be great if you can test again. If the problem still exists I will >> post a bug report for pjsip. >> >> http://www.ipcom.at/fileadmin/ipcom/files/qjsimple/QjSimple-0.6.6.zip >> >> regards >> Klaus >> >> Am 21.04.2011 10:10, schrieb Pavel Segeč: >>> Hi Klaus, >>> >>> I'm testing your QJSimple client and I'm observing following problems. >> In a IPv4 environments (win 7/32 or 64bit), the client is using a >> classical DNS resolving with SRV and so on, and I'm able to register. >> But inside of the IPV6 environment (IPv4 disabled), when UDP transport >> is used, the client is making just the A DNS record resolving on my >> domain name, not SRV at all. >>> >>> Here is debug log: >>> >>> QjSimple: starting registration ... >>> QjSimple: initializing SIP stack ... >>> QjSimple: pjsua_create succeeded ... >>> QjSimple: "qjsimple" memory pool created ... >>> QjSimple: DLL loaded ... >>> QjSimple: GetNetworkParams found ... >>> QjSimple: GetNetworkParams done ... >>> QjSimple: cfg.nameserver_count=0 >>> QjSimple: pjsua_init succeeded ... >>> QjSimple: pjsip_endpt_register_module succeeded ... >>> QjSimple: adding UDP transport ... >>> QjSimple: pjsip_endpt_register_module succeeded ... >>> QjSimple: outboundUri=sip:ps.sip.uniza.sk;lr;transport=udp >>> QjSimple: publish_enabled=FALSE >>> QjSimple: pjsua_acc_add succeeded ... >>> QjSimple: finished intializing SIP stack, start pjsua ... >>> QjSimple: initializing SIP stack ... done >>> QjSimple: Info: on_reg_state_slot called >>> QjSimple: Info: on_reg_state_slot: status=502 >>> QjSimple: Info: on_reg_state_slot: statustext=Bad Gateway >>> >>> When I setup as the transport protocol UDP6 there is no actions at >> all, no dns, no sip, he re is debug log >>> >>> QjSimple: starting registration ... >>> QjSimple: initializing SIP stack ... >>> QjSimple: pjsua_create succeeded ... >>> QjSimple: "qjsimple" memory pool created ... >>> QjSimple: DLL loaded ... >>> QjSimple: GetNetworkParams found ... >>> QjSimple: GetNetworkParams done ... >>> QjSimple: cfg.nameserver_count=0 >>> QjSimple: pjsua_init succeeded ... >>> QjSimple: pjsip_endpt_register_module succeeded ... >>> QjSimple: adding UDP6 transport ... >>> QjSimple: pjsip_endpt_register_module succeeded ... >>> QjSimple: outboundUri=sip:ps.sip.uniza.sk;lr;transport=udp >>> QjSimple: publish_enabled=FALSE >>> QjSimple: pjsua_acc_add succeeded ... >>> QjSimple: finished intializing SIP stack, start pjsua ... >>> QjSimple: initializing SIP stack ... done >>> >>> regards >>> >>> pavel >>> >>>> -----Original Message----- >>>> From: sr-users-bounces(a)lists.sip-router.org [mailto:sr-users- >>>> bounces(a)lists.sip-router.org] On Behalf Of Klaus Darilion >>>> Sent: Wednesday, April 20, 2011 12:49 PM >>>> To: sr-users(a)lists.sip-router.org >>>> Subject: Re: [SR-Users] Ipv6 SIP UA >>>> >>>> >>>> >>>> Am 20.04.2011 11:01, schrieb Pavel Segeč: >>>>> Hi, >>>>> >>>>> yes I can agree now, linphone is working well, qjsimple has some >>>> problem >>>> >>>> If you find some problems (except that it does not work over TCL/TLS: >>>> http://trac.pjsip.org/repos/ticket/1127) please let me know. >>>> >>>> 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 >>>> >>>> >>>> __________ Informacia od ESET NOD32 Antivirus, verzia databazy 6057 >>>> (20110420) __________ >>>> >>>> Tuto spravu preveril ESET NOD32 Antivirus. >>>> >>>> http://www.eset.sk >>>> >>>> >>>> __________ Informacia od ESET NOD32 Antivirus, verzia databazy 6059 >>>> (20110420) __________ >>>> >>>> Tuto spravu preveril ESET NOD32 Antivirus. >>>> >>>> http://www.eset.sk >>>> >>> >>> >>> __________ Informacia od ESET NOD32 Antivirus, verzia databazy 6059 >> (20110420) __________ >>> >>> Tuto spravu preveril ESET NOD32 Antivirus. >>> >>> http://www.eset.sk >>> >>> >> >> _______________________________________________ >> 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 >> >> >> __________ Informacia od ESET NOD32 Antivirus, verzia databazy 6060 >> (20110421) __________ >> >> Tuto spravu preveril ESET NOD32 Antivirus. >> >> http://www.eset.sk >> > > > __________ Informacia od ESET NOD32 Antivirus, verzia databazy 6060 (20110421) __________ > > Tuto spravu preveril ESET NOD32 Antivirus. > > http://www.eset.sk > > > > _______________________________________________ > 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

3 2

Try backup route
by qmail＠top-consulting.net 22 Apr '11

22 Apr '11

I'm using Kamailio 3.1 I have a custom routing statement called MYROUTE which is placed like this: route { ... route (MYROUTE); route (RELAY);} Inside MYROUTE I do some custom SQL checking that basically selects the least cost provider for the ongoing call. The MYROUTE routine sets the $rU, $rd and $rp variables in case a provider has been found for the dialed number or fails with Sip code 404. All this works perfectly, except in my database I also have an alternate provider that I only wish to use as backup in case the main provider returns a 5XX code. How do I get Kamailio to try the second provider after the first one failed ? So far I've tried setting up a t_on_failure() command & routine that picks up the backup provider from the database and sets $rU, $rd margin-right:0px;margin-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;"> 0(11460) DEBUG: [parser/msg_parser.c:167]: get_hdr_field: cseq : 0(11460) DEBUG: [parser/msg_parser.c:201]: DEBUG: get_hdr_body : content_length=0 0(11460) DEBUG: [parser/msg_parser.c:103]: found end of header 0(11460) DEBUG: maxfwd [mf_funcs.c:66]: max_forwards header not found! 0(11460) DEBUG: [parser/parse_to.c:174]: DEBUG: add_param: tag=4a2aab60 0(11460) DEBUG: [parser/parse_to.c:803]: end of header reached, state=29 0(11460) DEBUG: siputils [checks.c:76]: totag found 0(11460) DEBUG: rr [loose.c:108]: No Route headers found 0(11460) DEBUG: rr [loose.c:910]: There is no Route HF I believe the problem is that t_on_failure() does not keep all the proper data associated with the call and that's why it fails. Maybe t_on_failure isn't the right command to use here after all (?). So to resume. Here's what I wish to achieve: 1 Call comes through2. Goes through MYROUTE where a provider is selected3. Call is attempted through provider found in #24. If call fails , select another provider5. Call is attempted through provider found in #4 Thanks!

2 1

Try backup route
by qmail＠polarismail.com 21 Apr '11

21 Apr '11

I'm using Kamailio 3.1 I have a custom routing statement called MYROUTE which is placed like this: route { ... route (MYROUTE); route (RELAY);} Inside MYROUTE I do some custom SQL checking that basically selects the least cost provider for the ongoing call. The MYROUTE routine sets the $rU, $rd and $rp variables in case a provider has been found for the dialed number or fails with Sip code 404. All this works perfectly, except in my database I also have an alternate provider that I only wish to use as backup in case the main provider returns a 5XX code. How do I get Kamailio to try the second provider after the first one failed ? So far I've tried setting up a t_on_failure() command & routine that picks up the backup provider from the database and sets $rU, $rd margin-right:0px;margin-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;"> 0(11460) DEBUG: [parser/msg_parser.c:167]: get_hdr_field: cseq : 0(11460) DEBUG: [parser/msg_parser.c:201]: DEBUG: get_hdr_body : content_length=0 0(11460) DEBUG: [parser/msg_parser.c:103]: found end of header 0(11460) DEBUG: maxfwd [mf_funcs.c:66]: max_forwards header not found! 0(11460) DEBUG: [parser/parse_to.c:174]: DEBUG: add_param: tag=4a2aab60 0(11460) DEBUG: [parser/parse_to.c:803]: end of header reached, state=29 0(11460) DEBUG: siputils [checks.c:76]: totag found 0(11460) DEBUG: rr [loose.c:108]: No Route headers found 0(11460) DEBUG: rr [loose.c:910]: There is no Route HF I believe the problem is that t_on_failure() does not keep all the proper data associated with the call and that's why it fails. Maybe t_on_failure isn't the right command to use here after all (?). So to resume. Here's what I wish to achieve: 1 Call comes through2. Goes through MYROUTE where a provider is selected3. Call is attempted through provider found in #24. If call fails , select another provider5. Call is attempted through provider found in #4 Thanks!

1 0

BLF using kamailio
by Lucas Alvarez 21 Apr '11

21 Apr '11

Hi, I have implemented kamailio with asterisk, I want to enable BLF using kamailio instead of asterisk. I would appreciate any kind of help, below I'm pasting my configuration. *I'm testing with an Aastra phone, when phone sends the subscription kamailio answers with:* U 192.168.15.22:5060 -> 192.168.15.108:5060 SIP/2.0 489 Bad Event. Via: SIP/2.0/UDP 192.168.15.108;branch=z9hG4bKa54a155ad67706dca. From: "1104" <sip:1104@192.168.15.22:5060>;tag=71cf5c9949. To: <sip:1104@192.168.15.22:5060>;tag=99b712eabe88b2bf7a20409f3dc7ebf1-f71b. Call-ID: f22823b8b4d58a8e. CSeq: 3430 SUBSCRIBE. Allow-Events: presence.winfo, presence, dialog. Server: kamailio (3.1.3 (i386/linux)). Content-Length: 0. *This is my presence configuration:* #!ifdef WITH_PRESENCE loadmodule "presence.so" loadmodule "presence_dialoginfo.so" loadmodule "presence_xml.so" #!endif #!ifdef WITH_PRESENCE # ----- presence params ----- modparam("presence", "db_url", DBURL) modparam("presence", "server_address", "sip:192.168.15.22:5060") modparam("presence_dialoginfo", "force_single_dialog", 1) # ----- presence_xml params ----- modparam("presence_xml", "db_url", DBURL) modparam("presence_xml", "force_active", 1) #!endif

4 5

New developer: Jason Penton
by Daniel-Constantin Mierla 21 Apr '11

21 Apr '11

Hello, I want to announce Jason Penton as a new registered developer, with write access to GIT repository - his username id is 'jason.penton'. Jason already submitted an IMS-related module that Carsten added to his IMS branch in the last days, therefore expect contributions from Jason in the IMS extensions. Thanks, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

2 1

Re: [SR-Users] Ipv6 SIP UA
by Klaus Darilion 21 Apr '11

21 Apr '11

Pavel, I have updated QjSimple to latest pjsip version (0.8.10). It would be great if you can test again. If the problem still exists I will post a bug report for pjsip. http://www.ipcom.at/fileadmin/ipcom/files/qjsimple/QjSimple-0.6.6.zip regards Klaus Am 21.04.2011 10:10, schrieb Pavel Segeč: > Hi Klaus, > > I'm testing your QJSimple client and I'm observing following problems. In a IPv4 environments (win 7/32 or 64bit), the client is using a classical DNS resolving with SRV and so on, and I'm able to register. But inside of the IPV6 environment (IPv4 disabled), when UDP transport is used, the client is making just the A DNS record resolving on my domain name, not SRV at all. > > Here is debug log: > > QjSimple: starting registration ... > QjSimple: initializing SIP stack ... > QjSimple: pjsua_create succeeded ... > QjSimple: "qjsimple" memory pool created ... > QjSimple: DLL loaded ... > QjSimple: GetNetworkParams found ... > QjSimple: GetNetworkParams done ... > QjSimple: cfg.nameserver_count=0 > QjSimple: pjsua_init succeeded ... > QjSimple: pjsip_endpt_register_module succeeded ... > QjSimple: adding UDP transport ... > QjSimple: pjsip_endpt_register_module succeeded ... > QjSimple: outboundUri=sip:ps.sip.uniza.sk;lr;transport=udp > QjSimple: publish_enabled=FALSE > QjSimple: pjsua_acc_add succeeded ... > QjSimple: finished intializing SIP stack, start pjsua ... > QjSimple: initializing SIP stack ... done > QjSimple: Info: on_reg_state_slot called > QjSimple: Info: on_reg_state_slot: status=502 > QjSimple: Info: on_reg_state_slot: statustext=Bad Gateway > > When I setup as the transport protocol UDP6 there is no actions at all, no dns, no sip, he re is debug log > > QjSimple: starting registration ... > QjSimple: initializing SIP stack ... > QjSimple: pjsua_create succeeded ... > QjSimple: "qjsimple" memory pool created ... > QjSimple: DLL loaded ... > QjSimple: GetNetworkParams found ... > QjSimple: GetNetworkParams done ... > QjSimple: cfg.nameserver_count=0 > QjSimple: pjsua_init succeeded ... > QjSimple: pjsip_endpt_register_module succeeded ... > QjSimple: adding UDP6 transport ... > QjSimple: pjsip_endpt_register_module succeeded ... > QjSimple: outboundUri=sip:ps.sip.uniza.sk;lr;transport=udp > QjSimple: publish_enabled=FALSE > QjSimple: pjsua_acc_add succeeded ... > QjSimple: finished intializing SIP stack, start pjsua ... > QjSimple: initializing SIP stack ... done > > regards > > pavel > >> -----Original Message----- >> From: sr-users-bounces(a)lists.sip-router.org [mailto:sr-users- >> bounces(a)lists.sip-router.org] On Behalf Of Klaus Darilion >> Sent: Wednesday, April 20, 2011 12:49 PM >> To: sr-users(a)lists.sip-router.org >> Subject: Re: [SR-Users] Ipv6 SIP UA >> >> >> >> Am 20.04.2011 11:01, schrieb Pavel Segeč: >>> Hi, >>> >>> yes I can agree now, linphone is working well, qjsimple has some >> problem >> >> If you find some problems (except that it does not work over TCL/TLS: >> http://trac.pjsip.org/repos/ticket/1127) please let me know. >> >> 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 >> >> >> __________ Informacia od ESET NOD32 Antivirus, verzia databazy 6057 >> (20110420) __________ >> >> Tuto spravu preveril ESET NOD32 Antivirus. >> >> http://www.eset.sk >> >> >> __________ Informacia od ESET NOD32 Antivirus, verzia databazy 6059 >> (20110420) __________ >> >> Tuto spravu preveril ESET NOD32 Antivirus. >> >> http://www.eset.sk >> > > > __________ Informacia od ESET NOD32 Antivirus, verzia databazy 6059 (20110420) __________ > > Tuto spravu preveril ESET NOD32 Antivirus. > > http://www.eset.sk > >

2 1

Re: [SR-Users] Ipv6 SIP UA
by Pavel Segeč 21 Apr '11

21 Apr '11

Hi, and the IMS Boghe client can be used for IPv6 call testing too. pavel > -----Original Message----- > From: sr-users-bounces(a)lists.sip-router.org [mailto:sr-users- > bounces(a)lists.sip-router.org] On Behalf Of Pavel Segeč > Sent: Thursday, April 21, 2011 10:10 AM > To: 'SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - > Users Mailing List' > Subject: Re: [SR-Users] Ipv6 SIP UA > > Hi Klaus, > > I'm testing your QJSimple client and I'm observing following problems. > In a IPv4 environments (win 7/32 or 64bit), the client is using a > classical DNS resolving with SRV and so on, and I'm able to register. > But inside of the IPV6 environment (IPv4 disabled), when UDP transport > is used, the client is making just the A DNS record resolving on my > domain name, not SRV at all. > > Here is debug log: > > QjSimple: starting registration ... > QjSimple: initializing SIP stack ... > QjSimple: pjsua_create succeeded ... > QjSimple: "qjsimple" memory pool created ... > QjSimple: DLL loaded ... > QjSimple: GetNetworkParams found ... > QjSimple: GetNetworkParams done ... > QjSimple: cfg.nameserver_count=0 > QjSimple: pjsua_init succeeded ... > QjSimple: pjsip_endpt_register_module succeeded ... > QjSimple: adding UDP transport ... > QjSimple: pjsip_endpt_register_module succeeded ... > QjSimple: outboundUri=sip:ps.sip.uniza.sk;lr;transport=udp > QjSimple: publish_enabled=FALSE > QjSimple: pjsua_acc_add succeeded ... > QjSimple: finished intializing SIP stack, start pjsua ... > QjSimple: initializing SIP stack ... done > QjSimple: Info: on_reg_state_slot called > QjSimple: Info: on_reg_state_slot: status=502 > QjSimple: Info: on_reg_state_slot: statustext=Bad Gateway > > When I setup as the transport protocol UDP6 there is no actions at all, > no dns, no sip, he re is debug log > > QjSimple: starting registration ... > QjSimple: initializing SIP stack ... > QjSimple: pjsua_create succeeded ... > QjSimple: "qjsimple" memory pool created ... > QjSimple: DLL loaded ... > QjSimple: GetNetworkParams found ... > QjSimple: GetNetworkParams done ... > QjSimple: cfg.nameserver_count=0 > QjSimple: pjsua_init succeeded ... > QjSimple: pjsip_endpt_register_module succeeded ... > QjSimple: adding UDP6 transport ... > QjSimple: pjsip_endpt_register_module succeeded ... > QjSimple: outboundUri=sip:ps.sip.uniza.sk;lr;transport=udp > QjSimple: publish_enabled=FALSE > QjSimple: pjsua_acc_add succeeded ... > QjSimple: finished intializing SIP stack, start pjsua ... > QjSimple: initializing SIP stack ... done > > regards > > pavel > > > -----Original Message----- > > From: sr-users-bounces(a)lists.sip-router.org [mailto:sr-users- > > bounces(a)lists.sip-router.org] On Behalf Of Klaus Darilion > > Sent: Wednesday, April 20, 2011 12:49 PM > > To: sr-users(a)lists.sip-router.org > > Subject: Re: [SR-Users] Ipv6 SIP UA > > > > > > > > Am 20.04.2011 11:01, schrieb Pavel Segeč: > > > Hi, > > > > > > yes I can agree now, linphone is working well, qjsimple has some > > problem > > > > If you find some problems (except that it does not work over TCL/TLS: > > http://trac.pjsip.org/repos/ticket/1127) please let me know. > > > > 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 > > > > > > __________ Informacia od ESET NOD32 Antivirus, verzia databazy 6057 > > (20110420) __________ > > > > Tuto spravu preveril ESET NOD32 Antivirus. > > > > http://www.eset.sk > > > > > > __________ Informacia od ESET NOD32 Antivirus, verzia databazy 6059 > > (20110420) __________ > > > > Tuto spravu preveril ESET NOD32 Antivirus. > > > > http://www.eset.sk > > > > > __________ Informacia od ESET NOD32 Antivirus, verzia databazy 6059 > (20110420) __________ > > Tuto spravu preveril ESET NOD32 Antivirus. > > http://www.eset.sk > > > > _______________________________________________ > 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 > > > __________ Informacia od ESET NOD32 Antivirus, verzia databazy 6059 > (20110420) __________ > > Tuto spravu preveril ESET NOD32 Antivirus. > > http://www.eset.sk > __________ Informacia od ESET NOD32 Antivirus, verzia databazy 6059 (20110420) __________ Tuto spravu preveril ESET NOD32 Antivirus. http://www.eset.sk

1 0

Re: [SR-Users] Ipv6 SIP UA
by Klaus Darilion 21 Apr '11

21 Apr '11

Am 20.04.2011 11:01, schrieb Pavel Segeč: > Hi, > > yes I can agree now, linphone is working well, qjsimple has some problem If you find some problems (except that it does not work over TCL/TLS: http://trac.pjsip.org/repos/ticket/1127) please let me know. klaus

2 1

xmlrpc requests counted as unsupported_methods
by Juha Heinanen 21 Apr '11

21 Apr '11

looks like core stats counts xmlrpc requests served by route [xmlrpc_requests] as unsupported_methods. is there anything a user can do about it or is it a bug that should be fixed? -- juha

2 4

Broken Via/reply-matching for natping OPTION
by Andreas Granig 20 Apr '11

20 Apr '11

Hi, When kamailio-3.1 sends OPTIONS for natping, the Via branch is wrong, e.g: OPTIONS sip:192.168.51.1:5060 SIP/2.0. Via: SIP/2.0/UDP 127.0.0.1:5062;branch=0. Route: <something> Should be branch=z9hG4bK<something> instead of branch=0, right? When a reply comes back, like this... SIP/2.0 100 Trying. Via: SIP/2.0/UDP 127.0.0.1:5062;branch=0;rport=5062. From: sip:pinger@<something> ... then kamailio logs this: INFO: <core> [forward.c:786]: broken reply to forward - no 2nd via The full debug log looks like this: DEBUG: <core> [parser_helpers.c:196]: path for branch: '<sip:lb@127.0.0.1:5060;lr;received=sip:192.168.51.1:5060>' DEBUG: <core> [parser/msg_parser.c:640]: SIP Reply (status): DEBUG: <core> [parser/msg_parser.c:642]: version: <SIP/2.0> DEBUG: <core> [parser/msg_parser.c:644]: status: <100> DEBUG: <core> [parser/msg_parser.c:646]: reason: <Trying> DEBUG: <core> [parser/parse_via.c:1287]: Found param type 232, <branch> = <0>; state=6 DEBUG: <core> [parser/parse_via.c:1287]: Found param type 235, <rport> = <5062>; state=16 DEBUG: <core> [parser/parse_via.c:2300]: end of header reached, state=5 DEBUG: <core> [parser/msg_parser.c:515]: parse_headers: Via found, flags=2 DEBUG: <core> [parser/msg_parser.c:517]: parse_headers: this is the first via DEBUG: <core> [receive.c:145]: After parse_msg... DEBUG: tm [t_lookup.c:1081]: DEBUG: t_check_msg: msg id=1 global id=0 T start=0xffffffffffffffff DEBUG: <core> [parser/parse_to.c:803]: end of header reached, state=9 DEBUG: <core> [parser/msg_parser.c:187]: DEBUG: get_hdr_field: <To> [23]; uri=[sip:192.168.51.1:5060] DEBUG: <core> [parser/msg_parser.c:189]: DEBUG: to body [sip:192.168.51.1:5060#015#012] DEBUG: <core> [parser/msg_parser.c:167]: get_hdr_field: cseq <CSeq>: <1> <OPTIONS> DEBUG: tm [t_lookup.c:1055]: DEBUG: t_reply_matching: failure to match a transaction DEBUG: tm [t_lookup.c:1150]: DEBUG: t_check_msg: msg id=1 global id=1 T end=(nil) DEBUG: <core> [parser/msg_parser.c:201]: DEBUG: get_hdr_body : content_length=0 DEBUG: <core> [parser/msg_parser.c:103]: found end of header INFO: <core> [forward.c:786]: broken reply to forward - no 2nd via DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil) Thanks, Andreas

4 6

planning next major release 3.2
by Daniel-Constantin Mierla 20 Apr '11

20 Apr '11

Hello, soon we should sketch the roadmap for the next major release 3.2. There are some private git branches with lot of work on it, so we need to synchronize a bit and decide about the proper time: before or after summer. Several devels will be in Berlin for Linuxtag, but no so much overlapping for a big face to face meeting, therefore might be better to have a IRC chat conference sometime in the near future. Next week will be fine for me, say Wednesaday till Friday, in the afternoon to allow fair time of the day for US timezones. If you have other proposals, speak up. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

2 3

Re: [SR-Users] Ipv6 SIP UA
by Daniel-Constantin Mierla 20 Apr '11

20 Apr '11

Hello, On 4/19/11 9:58 AM, Pavel Segeč wrote: > Hi, > > may someone help me and recommend a software SIP client with a good IPv6 > support implemented? I tried Xlite, Bria, Linphone, SIP communicator and > Jitsi but with a bad results. Each have some problem within pure IPv6 > environment. the last sipit I attended (last year, though) was not rich at all in IPv6 softphones. In the past there was a patched version of KPhone we used at FhG Fokus for some tests, but I wouldn't call it production ready: http://old.iptel.org/products/kphone/ From what was listed above, you touched most of the active softphones, afaik ekiga,qutecom and twinkle do not have it, not sure about zoiper. Cheers, Daniel

4 3

Re: [SR-Users] Ipv6 SIP UA
by Klaus Darilion 19 Apr '11

19 Apr '11

I once wrote a SIP client based on pjsip: http://www.ipcom.at/en/telephony/qjsimple/ AFAIK it works will using IPv6 when using UDP. regards Klaus Am 19.04.2011 09:58, schrieb Pavel Segeč: > Hi, > > may someone help me and recommend a software SIP client with a good IPv6 > support implemented? I tried Xlite, Bria, Linphone, SIP communicator and > Jitsi but with a bad results. Each have some problem within pure IPv6 > environment. > > palo > > > __________ Informacia od ESET NOD32 Antivirus, verzia databazy 6053 > (20110418) __________ > > Tuto spravu preveril ESET NOD32 Antivirus. > > http://www.eset.sk > > > > _______________________________________________ > 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

ser flavour accounting
by Claudio Furrer 19 Apr '11

19 Apr '11

Hello, I'm trying to migrate ser-0.9.x to the current sr-3.1.x and right now trying to figure out the acc functions/parameters. I used to use "acc_db_request" from acc module, but it's not working using acc_db and acc_syslog in conjuntion. acc_db has acc_db_request[0,1] but are not callable from the configuration file, and acc_syslog has acc_db_request, but doesn't matter if i load this module, the function isn't found... loading modules under /usr/lib/siprouter/modules:/usr/lib/siprouter/modules_s 0(23455) : <core> [cfg.y:3412]: parse error in config file /tmp/ser.cfg, line 358, column 74: unknown command, missing loadmodule? line 358 is: acc_db_request("480 Offline User", "missed_calls"); I would appreciate if you can guide me through the ACC documentation or changes that it has suffered.. I tried to track the git log.. but many changes since my old ser :( Thank you Claudio pd: FYI i did this modifications to adjust my acc settings: # Accounting module +loadmodule "acc_syslog.so" loadmodule "acc_db.so" # ----------------- setting module-specific parameters --------------- @@ -139,15 +140,13 @@ # number of flag, which will be used for accounting; if a message is # labeled with this flag, its completion status will be reported # modparam("acc", "log_flag", 1 ) -modparam("acc_db", "log_level", 1) +modparam("acc_syslog", "log_level", 1) # MySQL acc params modparam("acc_db", "db_url", "mysql://ser:heslo@localhost/ser") -modparam("acc_db", "db_flag", 2) -modparam("acc_db", "db_missed_flag", 3) +modparam("acc_db", "log_flag", 2) +modparam("acc_db", "log_missed_flag", 3) modparam("acc_db", "log_fmt", "miocfspD") -# Acc time set to localtime (1) -modparam("acc_db", "db_localtime", 1)

2 1

modules_s/uri_db functions
by Claudio Furrer 19 Apr '11

19 Apr '11

Hello, What happened to checks.c file on uri_db module (modules_s)? Seem to be an empty file now, only headers exist. Is it the same to use modules_k/ version? I'm currently at v3.1.. Regards, Claudio

2 1

tm stats pseudo variables?
by Juha Heinanen 19 Apr '11

19 Apr '11

is there any means to access native tm stats from script? i know about $stat pvs for accessing k versions of tm stats, but i want access to native tm stats. -- juha

3 2

RTPProxy and bridging IPv4/IPv6 with parallel forking
by Dan-Cristian Bogos 19 Apr '11

19 Apr '11

Hey Guys, I was recently playing with gateway-ing IPv4-IPv6 and hit the following scenario: * AOR having contacts on both ipv4 and ipv6 and I wanted to do parallel forking. RTPProxy bridging works without any issue on a normal setup, however the problem shows up when needing to make calls toward rtpproxy to return both sides of bridge or only one (ee and ie combinations). Did any of you experiment with this scenario? EG: Call comes from ipv4, you want to send it to both ipv4 and ipv6. The branch route looks the right place to call rtpproxy but when calling unforce_rtp_proxy() on CANCEL, will rtpproxy be aware about which ports are we trying to cancel? One more issue would be with re-invite which must go out with the same ip of rtpproxy as original INVITE. Here we could store the bridge direction in some route parameter but unfortunately adding route params is not possible in branches. So what do u think? DanB PS: The "normal" setup of forking calls only ipv4 or only ipv6 works smooth, so support of ipv6 in kamailio or rtpproxy is not questionable.

4 10

stats in kamailio
by Ricardo Martinez 19 Apr '11

19 Apr '11

Hello. I’m trying to get statistics to use charts in SIREMIS v2.0. I was able to load the “Memory” statistics but I want to know if there is more information to use from Kamailio, right now I have : $stat(used_size) $stat(real_used_size) $stat(max_used_size) $stat(free_size) $stat(location-users) $stat(location-contacts) Where can I find the complete list of statistics to get from kamailio?. Thanks in advance. Ricardo Martinez.-

5 13

Attended transfer in load-balanced multi-server setup
by Pan B. Christensen 18 Apr '11

18 Apr '11

Hello all, I'm having problems with attended transfer in certain scenarios. Let me first try to document the relevant parts of the setup: There are two load-balanced Asterisk gateways connected to the old Nortel system. Currently, PSTN connections are done by Nortel. We then have two load-balanced kamailio servers. The phones are connected to these. There are several other servers not relevant to this question. Blind transfer works in any scenario. I've been told that attended transfer works in any scenario if the original call is SIP to SIP. If the original call is from Nortel/PSTN to SIP, then attended transfer will usually not work. Scenarios: A call comes in from Nortel/PSTN (user A) through Nortel1 to a SIP device (user B). User B pushes the transfer button (puts current call on hold and makes a new call) and dials a Nortel / PSTN number to user C. This call goes out through the nortel2 server. Users B and C talk a short while before user B pushes the Transfer button again to connect users A and C. In this scenario, the REFER is forwarded by kamailio to nortel1, which replies "SIP/2.0 481 Call leg/transaction does not exist." The call to join is of course on the other asterisk (nortel2). A similar scenario is where user B transfers to another SIP user. This call will only exist in one of the kamailio servers, and Asterisk will give the same response to the REFER. A third scenario is where both calls are handled by the same Asterisk server. This scenario works. I'm assuming I'll have to build REFER-handling logic into kamailio, but am unsure of how to proceed. Any suggestions? Thanks in advance. With kind regards, Pan

2 2

Notifying RLS when XML documents are updated
by Peter Dunkley 18 Apr '11

18 Apr '11

Hello, I am using Kamailio RLS and integrated XCAP Server. When I add a contact with my client it updates my XCAP documents but there is no additional SIP messaging between the client and Kamailio. I have been assured (by the client author) that this is the correct behaviour. However, having looked at both the XCAP Server and RLS module code I cannot see anything that will either inform RLS that a document has been updated or a timer to check for that. Have I missed something obvious? Thanks, Peter -- Peter Dunkley Technical Director Crocodile RCS Ltd

1 0

perlvdb error
by Roman Yeryomin 18 Apr '11

18 Apr '11

Hi! I'm trying to use perlvdb module but seems that it's not working. Seems that needed functions are not exported correctly: kamailio[11525]: ERROR: <core> [db.c:79]: module db_perlvdb does not export db_use_table function Looking at perlvdb.c one can see that module exports it's functions as "perlvdb", not "db_perlvdb". But changing "perlvdb" to "db_perlvdb" results in segfault when running: kamailio[31336]: segfault at 1 ip b7365e3a sp bfa82fb0 error 4 in perlvdb.so[b7362000+6000] Do I misunderstand something completely or there is a bug? Anyone actually tried using this module or it just sits there forgotten? Regards, Roman

3 3

Probing mode howto?
by Spinov Evgeniy 18 Apr '11

18 Apr '11

Hello, all. Is there any possibility to set one of dispatcher destinations to probing mode manually? I can set it to active/inactive, however cannot set it to probing via MI. This is really required as, for instance, when asterisk reload takes like 1 minute to reload ( huge DB ), I want to set node to inactive first to do not make call attempts, and after reload set it to probing. Thank you.

1 0

loose_route security
by Eric Hiller 18 Apr '11

18 Apr '11

As I look and play with loose_route functionality it seems that by simply placing a route: proxyip;lr header in my invite I can bypass any and all security otherwise built into the configuration. Is this the way everyone has it? I have been unable to find any configuration examples online that show how to secure/restrict access to loose_route? Ideas or suggestions? Thanks, Eric

9 27

Fwd: [RAI] SIPit 28 summary
by Klaus Darilion 17 Apr '11

17 Apr '11

-------- Original-Nachricht -------- Betreff: [RAI] SIPit 28 summary Datum: Fri, 15 Apr 2011 10:47:08 -0500 Von: Robert Sparks <rjsparks(a)nostrum.com> An: rai(a)ietf.org Also available at <https://www.sipit.net/SIPit28_summary> RjS -------- SIPit 28 was hosted by Digium in Huntsville, Alabama, USA the week of Arpil 11-15, 2010. There were 54 attendees from 19 companies visiting from 10 countries. We had 40 distinct implementations. The roles represented (some implementations act in more than one role) 34 endpoints 6 proxy/registrars/b2bua/sbcs 1 dedicated event server Implementations using each transport for SIP messages: UDP 98% TCP 95% TLS 68% server-auth, 50% mutual-auth SCTP 10% DTLS 0% 68% of the implementations present supported IPv6. There was one RFC4474 Identity implementation present. For DNS we had support for: Full RFC3263 : 53% SRV only : 33% A records only : 15% no DNS support : 0% Support for various items in the endpoints: 76% replaces 38% 5389stun 26% turn 24% 3489stun 24% ice 21% sip/stun multiplexing 21% outbound 21% gruu 18% path 18% join 18% diversion 6% history-info (there were no implementations of 4244bis) 3% service-route 3% sigcomp Support for various items in the proxy/registrars: 50% path 50% outbound 33% sip/stun multiplexing 20% diversion 18% gruu 17% history-info 17% service-route The endpoints and B2BUAs implemented these methods: 100% INVITE, CANCEL, ACK, BYE 94% REGISTER 91% OPTIONS 91% REFER 82% NOTIFY 82% INFO 79% UPDATE 71% SUBSCRIBE 68% PRACK 47% PUBLISH 29% MESSAGE 94% of the implementations sent RTP from the port advertised for reception (symmetric-rtp). One of the implementations required the other party to use symmetric-rtp. 88% of the UAs present both sent RTCP and paid attention to RTCP they received. 56% of the endpoints present supported SRTP using sdes. There was one dtls-srtp implementations at this SIPit. 67% of the endpoints supported multipart/MIME. There were no implementations present with S/MIME support. 48% of the implementations present followed RFC6026 (corrections to the INVITE transaction) 68% followed RFC4320 (corrections to the non-INVITE transaction) There were 5 SIP Event Server implementations (not counting endpoints that support events only for refer). There were 9 SIP Event Client implementations (not counting endpoints that support events only for refer). These event packages were supported: Server Client 2 3 presence 1 0 presence.winfo 1 6 message-summary 2 5 dialog 0 2 reg 2 1 conference 1 0 xcap-diff 0 1 kpml These packages were supported with the eventlist extension: Server Client 1 0 presence Five of the proxies present still rely only on max-forwards. There was one implementation of fork-loop-fix, but no implementations of max-breadth. Multiparty tests (Thanks to Eoin McLeod for contributing notes for several tests) The Forking test was very well attended. We had the majority of the participants at the multiparty table. Many teams took away good new information from watching their implementation react to multiple merges and to Via stacks with transports switching between IPv4 and IPv6. Forcing multiple 200 Oks was more difficult than usual given the network equipment at hand. We've created a set of standing automated tests that will allow endpoints and proxies to test that scenario at their leisure. The TLS multiparty leveraged DNS to reduce configuration churn. We ensured a full mesh of connections between participating elements. There were some issues uncovered with the values used in Route/Record-Route not matching the configured certificates at an element. We brainstormed a configuration for the next event that will efficiently expose whether elements are correctly opening a new connection (rather than reusing an existing connection) when a new request with a resource belonging to an authority not matching what had been authenticated on the existing connection arrived. The SRTP tests showed a high level of interoperability (all with SDES keying), including hold/resume and transfer scenarios. There was a successful test of a call with media running long enough to increment the ROC, followed by a hold/resume. Several participants were trying variants of "best-effort/opportunistic" encryption with lower levels of success. These elements tested providing offers with both RTP/AVP and RTP/SAVP media-lines describing the same logical media channel, and with multiple RTP/AVP media lines decorated with different crypto attributes. The STUN/TURN/ICE tests had very high levels of interoperability. The test scenario involved elements in two natted networks sharing the same address space and elements in the public address space (including a separate TURN server for each of the private network islands). We had a mix of elements that supported relay allocation and elements that presented only host/reflexive candidates. A few elements assumed that all of the m-lines in an offer had to present ICE candidates. SDP with a mix of ICE enabled m-lines and m-lines without candidates caused ICE failures. The Outbound test showed several successful flows being created and maintained. A mesh of edge-proxies and proxy/registrars were set up and endpoints established flows through several combinations. There was good UA support for the Flow-Timer, but there were implementations present that didn't randomize the keepalive value. There was not much testing of recovery from failed flows at this event - we'll focus on that at SIPit 29. We held a long multiparty session focusing on exchanging video with constrained bandwidth or impaired (latent or lossy) networks. There was a high level of basic interoperability and reasonable reaction to mid-call shifts in network conditions, but all parties involved came away with changes they wanted to make in their implementations. The Spiral test presented requests to the participating UAs containing a mix of UDP, TCP, and TLS over IPv4 and IPv6 values in large Via and Record-Route stacks. Correct operation of subsequent in-dialog requests in both directions was tested, discovering a few implementation problems, and some invalid assumptions about how dialog-stateful proxies might need to behave, but most scenarios worked well. We followed the usual Spiral test with a "fuzz-ball" test utilizing DNS SRV to randomly distribute the propagation of messages through all of the proxies present, hopping off to the UAs with a low probability, resulting in an easy-to-configure test that exercised a full-mesh of connections between proxies and presented the UAs with very diverse (and large) Via and Record-Route header field values. We exercised the RFC5393 proxy-doom scenario, again leveraging the SRV load-leveling capabilities to simplify configuration. We had messages popping out to the UAs from each level of the tree, giving them a very large-scale merge test. _______________________________________________ RAI mailing list RAI(a)ietf.org https://www.ietf.org/mailman/listinfo/rai

6 11

Meeting in San Francisco
by Daniel-Constantin Mierla 14 Apr '11

14 Apr '11

Hello, I will spend few days in San Francisco area, during May 6-10. If someone wants to meet and discuss about the project, VoIP & stuff, drop me an email. In case there are many people leaving close to SF city, then I can even try to arrange a group meeting, for a dinner or so, to map faces to names and have good drinks -- this decision will be announced later based on feedback, however suggestions about good meeting places are welcome from anyone. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

1 0

Re: [SR-Users] Problems with siremis custom charts
by Daniel-Constantin Mierla 14 Apr '11

14 Apr '11

Do not send me message privately upon answers on the mailing list - keep the mailing list always cc-ed otherwise the messages will be ignored. On 4/14/11 3:02 PM, Camila Troncoso wrote: > > Daniel, > > I want a bars graph and i´m using another table, one that I create. > The graph displays well with the default configuration (the one that > the other graph of siremis have) but I don´t want an area graph. I > search around siremis files and find a file named charts-lib.php. I > suppose this is the script that creates the graphs , but in this file > are only two type of graphs describe near line 130 ( area and > line_dot). I don’t know if this is why I can´t change the graph type. > yes, so far these are the ones supported by siremis for building custom graphs. The type, one of them, is taken from the xml config files describing the graphs. The library for making graphs supports other types, as you could see in the usrloc charts, but that is using a different php code base than the other grpahs. If you want to enhance it with other types of graphs, that would be great and if you send a working patch then we can include it in the next release. Cheers, Daniel > > Regards, > > Camila > > *From:*Daniel-Constantin Mierla [mailto:miconda@gmail.com > <mailto:miconda@gmail.com>] > *Sent:* jueves, 14 de abril de 2011 6:16 > *To:* SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - > Users Mailing List > *Cc:* Camila Troncoso > *Subject:* Re: [SR-Users] Problems with siremis custom charts > > Hello, > > On 4/13/11 10:56 PM, Camila Troncoso wrote: > > Hi, > > I´m having problems with siremis charts. I create a new graph and all > is working fine, but I want to use another type of graph ( the default > graphs of siremis uses type=”area”) and when I change the graph type > to any other thing it shows me the same graph but only the area under > the curve isn´t paint , but the curve doesn´t change. > > Please some help with this issue… > > what type of graph you try to use? have you checked the database > statistics table records, do they have different values for this > graph? If not, check if you write the desired values from the kamailio > config file there. > > Cheers, > Daniel > > -- > Daniel-Constantin Mierla > http://www.asipto.com -- Daniel-Constantin Mierla http://www.asipto.com

1 0

How I can turn off 100 trying reply
by Derrick Ding 14 Apr '11

14 Apr '11

Hi, All I wonder how I can make Kamailio not to send "100 Trying" msg when receive INVITE request, by modifying kamailio.cfg or source code. Thanks Derrick

4 10

Problems with siremis custom charts
by Camila Troncoso 14 Apr '11

14 Apr '11

Hi, I´m having problems with siremis charts. I create a new graph and all is working fine, but I want to use another type of graph ( the default graphs of siremis uses type=”area”) and when I change the graph type to any other thing it shows me the same graph but only the area under the curve isn´t paint , but the curve doesn´t change. Please some help with this issue… Regards, Camila T. *Camila Troncoso **|* Ingeniero de Desarrollo RedVoiss *|*ctroncoso(a)redvoiss.net Santiago - Chile *|* +56 2 2408535 www.redvoiss.net

2 1

Problems with db_text
by Sascha Daniels 14 Apr '11

14 Apr '11

Hi together, I am trying to make a setup with kamailio and freeswitch, that can run with all supported database types. The basic setup is from this howto: http://kb.asipto.com/freeswitch:kamailio-3.1.x-freeswitch-1.0.6d-sbc With mysql everything is (more or less) fine. Creating db_text databases does not work because /opt/kamailio-3.1/share/kamailio/dbtext/kamailio/uacreg is missing and kamdbctl gives up. Just created an empty file, so kamdbctl can finish its work. The subscribers database is created (works in a more simple setup). Now I am getting this error when starting kamailio: http://pastebin.com/vsiUNdCM Version of table: pua:6 Why does the table version not exist? It was created by "kamdbctl create". I am a bit lost with this debug output. Greets Sascha -- AMOOMA GmbH - Bachstr. 124 - 56566 Neuwied --> http://www.amooma.de Geschäftsführer: Stefan Wintermeyer, Handelsregister Montabaur B14998 Bücher: http://das-asterisk-buch.de - http://ruby-auf-schienen.de

1 0

Problems with siremis custom charts
by Camila Troncoso 13 Apr '11

13 Apr '11

Hi, I´m having problems with siremis charts. I create a new graph and all is working fine, but I want to use another type of graph ( the default graphs of siremis uses type=”area”) and when I change the graph type to any other thing it shows me the same graph but only the area under the curve isn´t paint , but the curve doesn´t change. Please some help with this issue… Regards, Camila T. *Camila Troncoso **|* Ingeniero de Desarrollo RedVoiss *|*ctroncoso(a)redvoiss.net Santiago - Chile *|* +56 2 2408535 www.redvoiss.net

1 0

Registrar Server, location and auth_db table
by Santiago Soares 12 Apr '11

12 Apr '11

Hello, I'm trying to use kamailio 1.5.3 as a registrar server. I have a table on my db that contains all user information, like username, password, expire time and ip address, so kamailio should use the same table to authenticate users AND save their location. The problem is that kamailio complains about table version when starts. It expects a different version number for location table and auth_db table. Is there any way I could use the same table for both functions? I'd appreciate any help! Thank you! -- Santiago Soares Fone: (41) 8488-0537

2 2

Re: [SR-Users] sr-users Digest, Vol 71, Issue 40
by Rick Aldred 12 Apr '11

12 Apr '11

Hi Fedrico, Sorry I missed your reply earlier (thanks by the way). I changed the service priority using the Services GUI utility under System | Administration as I didn't know about the update-rc.d command at the time. Maybe the GUI doesn't do all that's required under the hood or maybe I missed something, but anyway it's working now so that's great. Regards, Rick ------------------------------ Hi, from the log you pasted is clear that the problem is that kamailio is starting before mysql. This because, as you said, they have the same priority and so, being the starting order alphabetical for the same priority, kamailio will start before mysql and cannot connect to mysql which is still not up. You told that changing kamailio priority didn't change the result. How did you change the priority? Did you use the update-rc.d command? Regards, Federico

1 0

OT - Sipwise is hiring SIP and Web hackers
by Andreas Granig 11 Apr '11

11 Apr '11

Hi guys, We're looking for experienced SIP (Kamailio, Sems) and Web (Perl/Catalyst, MySQL, HTML/CSS/jQuery) hackers to work on our sip:provider CE platform and their commercial counter-parts. It's on-site (Vienna/Austria), full-time (40h/week) positions, so please no consultancy or free-lancing offers. http://www.sipwise.com/news/jobs/sipwise-is-hiring-perl-web-developers-arou… http://www.sipwise.com/news/jobs/sipwise-is-hiring-voip-engineers-around-vi… If you're interested, please drop us an email at office(a)sipwise.com. Thanks, Andreas

1 0

pua_xmpp presence problem with notify
by Martin Pohančeník 11 Apr '11

11 Apr '11

Hi ! I have managed to get the XMPP module working for IM. Now I am working on Presence service with the pua_xmpp module. I have experienced some problems and I would like to ask some questions to clarify my understandig of Kamailio. When a SUBSCRIBE arrives to Kamailio, it adds a subscribtion to the watchers table in the database. And if the subscriber is online, he is also in the active_watchers table, right? Next... when a PUBLISH request arrives to Kamailio, by default the handle_publish() function is called. This function generates all NOTIFY msgs (based on the database content of watchers and presence rules) and send them to the recipients. I wanted to ask if these generated NOTIFY msgs go through the routing logic, or not ? As I was saying, I was trying to get pua_xmpp module working, but Kamailio does not seem to send NOTIFY to users in XMPP (winfo is sent, bude presence itself is not). Here is a piece of my configuration file: if(is_method("NOTIFY")) { xlog(" ==== NOTIFY msg ====\n"); } if(is_method("NOTIFY") && uri=~"sip:.+[*].+@sip.sk") { xlog(" ====== NOTIFY from $fu to $tu ======\n"); if(pua_xmpp_notify()) { xlog(" ====== NOTIFY to xmpp domain from $fu to $tu ======\n"); t_reply("200", "OK"); } exit; } if(is_method("PUBLISH")) { xlog("===== PUBLISH FROM $fu ====="); handle_publish(); t_release(); } else if( is_method("SUBSCRIBE")) { handle_subscribe(); if(uri=~"sip:.+[*].+@sip.sk" && $hdr(Event)== "presence") { xlog(" ====== SUBSCRIBE for XMPP domain from $fu to see $tu ======\n"); pua_xmpp_req_winfo("$ruri", "$hdr(Expires)"); } t_release(); } exit; Based on this configuration, I never get the " ==== NOTIFY msg ====" output to the syslog. So I assume the NOTIFY never goes through the routing logic. Is that right?? If so, how can I get it to pass the routing logic so the pua_xmpp_notify() function can be executed ?? Is there any way to do this?? Regards Martin

2 2

Re: [SR-Users] Kamailio and several Asterisk - Realtime DB Integration (solved)
by Alejandro Rios P. 11 Apr '11

11 Apr '11

Hello Daniel Thanks for pointing out to the SIP traces. I found out that it if the request is to be sent to a destination using a port other than 5060, it is required to add the $uac_req(ouri) parameter too: $uac_req(ouri)="sip:" + $var(asterisk_ip) + ":" + $var(asterisk_port); .... $uac_req(ouri)="sip:" + $var(asterisk2_ip) + ":" + $var(asterisk2_port); Thanks! Alejandro Rios Peña <alerios(a)debian.org> DISCLAIMER: The opinions expressed are my own, and not necessarily those of my employer. <http://www.avatar.com.co> 2011/4/8 Daniel-Constantin Mierla <miconda(a)gmail.com> > Hello, > > > On 4/8/11 12:28 AM, Alejandro Rios P. wrote: > >> >> Hi all, >> >> I am testing the scenario described here: >> http://kb.asipto.com/asterisk:realtime:kamailio-3.1.x-asterisk-1.6.2-astdb >> >> It works great with one instance of Asterisk, but now that I'm testing >> with two Asterisk instances to load balance, and I see a problem regarding >> the registration forwarding to the second Asterisk. >> >> I tried adding a second "uac_req_send()" bellow the first one, but >> Kamailio only sends the first request and the REGISTER never gets to the >> second Asterisk: >> >> # Forward REGISTER to Asterisk >> route[REGFWD] { >> if(!is_method("REGISTER")) >> { >> return; >> } >> $var(rip) = $sel(cfg_get.asterisk.bindip); >> $uac_req(method)="REGISTER"; >> $uac_req(ruri)="sip:" + $var(rip) + ":" + >> $sel(cfg_get.asterisk.bindport); >> $uac_req(furi)="sip:" + $au+ "@" + $var(rip); >> $uac_req(turi)="sip:" + $au+ "@" + $var(rip); >> $uac_req(hdrs)="Contact:<sip:" + $au+ "@" >> + $sel(cfg_get.kamailio.bindip) >> + ":" + $sel(cfg_get.kamailio.bindport) >> + ">\r\n"; >> if($sel(contact.expires) != $null) >> $uac_req(hdrs)= $uac_req(hdrs) + "Expires:" + >> $sel(contact.expires) + "\r\n"; >> else >> $uac_req(hdrs)= $uac_req(hdrs) + "Expires:" + >> $hdr(Expires) + "\r\n"; >> uac_req_send(); >> >> $uac_req(all) = null; >> >> $var(rip2) = $sel(cfg_get.asterisk2.bindip); >> $uac_req(method)="REGISTER"; >> $uac_req(ruri)="sip:" + $var(rip2) + ":" + >> $sel(cfg_get.asterisk2.bindport); >> $uac_req(furi)="sip:" + $au+ "@" + $var(rip2); >> $uac_req(turi)="sip:" + $au+ "@" + $var(rip2); >> $uac_req(hdrs)="Contact:<sip:" + $au+ "@" >> + $sel(cfg_get.kamailio.bindip) >> + ":" + $sel(cfg_get.kamailio.bindport) >> + ">\r\n"; >> if($sel(contact.expires) != $null) >> $uac_req(hdrs)= $uac_req(hdrs) + "Expires:" + >> $sel(contact.expires) + "\r\n"; >> else >> $uac_req(hdrs)= $uac_req(hdrs) + "Expires:" + >> $hdr(Expires) + "\r\n"; >> uac_req_send(); >> >> } >> >> I also tried appending another branch and sending the second >> uac_req_send() from there, but it is not being sent. >> >> How can I use uac_req_send() several times for the same request or in >> parallel? >> > it should work one after the other. append_branch() does not affect > uac_req_send() at all, this is a separate request built from scratch. > > Do you get any error message in the syslog? Can you watch the traffic on > all interfaces 'ngrep -d any -qt -W byline port 5060' ? > > I see you assign '$uac_req(all) = null;', it should be '$uac_req(all) = > $null;' - but I guess it was a copy&paste thing. > > Cheers, > Daniel > > -- > Daniel-Constantin Mierla > http://www.asipto.com > >

2 3

Possible bugs in nathelper
by Peter Dunkley 11 Apr '11

11 Apr '11

Hello, I think I have found two bugs in nathelper in Kamailio 3.1.3. Has anyone else encountered these? Bug one ------- nat_uac_test() doesn't seem to work for requests that arrive over UDP. I tried with the latest versions of X-Lite and Jitsi for Windows and observed the same behaviour with both. As far as I could tell the UDP and TCP REGISTER methods were identical except for transport, Call-ID, tags (and so on). At the moment I have worked around this by treating all UDP requests as if they have come from behind a NAT - but this is not ideal. Bug Two ------- nat_uac_test() with flag bit 8 (SDP checks) set fails with an error if the request does not contain SDP. I don't think this is correct behaviour as it seems quite sensible to me to push all requests through the same NAT detection route. In this case it is quite likely that only some of the methods will contain SDP. Surely in this case the correct thing would be for the SDP checks to fail, but not be treated as an error? Thanks for you help, Peter -- Peter Dunkley Technical Director Crocodile RCS Ltd

2 5

Setting Global Variables
by Nathaniel L Keeling 11 Apr '11

11 Apr '11

Hello, I am trying to use global variables within my configuration script. I am using Kamailio v3.0.0 and I am following the syntax example written in the sample config file but I keep getting syntax errors. Here is a copy of my syntax and I am using cfg_get.voicemailserver.bindip to get the value. #!ifdef WITH_VOICEMAIL voicemailserver.bindip = "10.0.0.1" desc "Voicemail Server IP Address" voicemailserver.bindport = "5060" desc "Voicemail Server Port" #!endif Here is the error that I am receiving: 0(1875) : <core> [cfg.y:3333]: parse error in config file /usr/local/kamailio-3.0.0/etc/kamailio/kamailio.cfg, line 156, column 17: syntax error 0(1875) : <core> [cfg.y:3333]: parse error in config file /usr/local/kamailio-3.0.0/etc/kamailio/kamailio.cfg, line 156, column 17: unknown config variable 0(1875) : <core> [cfg.y:3330]: parse error in config file /usr/local/kamailio-3.0.0/etc/kamailio/kamailio.cfg, line 156, column 19-28: ERROR: bad config file (3 errors) 0(1875) DEBUG: <core> [mem/shm_mem.c:236]: shm_mem_destroy Thanks Nathaniel

2 1

Problems with dispatcher policy in HA/LB kamailio/asterisk environment
by Sören Berger 11 Apr '11

11 Apr '11

Hi all, I currently setup a HA/LB conference. I currently have 1 SER and 2 asterisk conference servers. The goal is to distribute the conferences based on the room number on different server. I use ubuntu 10.04 LTS and the packages from http://deb.kamailio.org/kamailio (kamailio_3.1.2+lucid1_amd64.deb) During the implementation I run into trouble with the "8 - first destination" policy which choose not my second server in case of a failure. The dial in is eg. 330 with round robin to any of my asterisk servers. There they check the room number and append it to the dial number. When somebody calls 330 and enter the room number 12345 the asterisk route it back to kamilio with 33012345 route[ASTERISK_CONFERENCE_AUTH] { if ($rU=~"(33[0-4]$)") { if ( method=="INVITE" ) { ds_select_dst("1","4"); forward(); exit(); } } } When the number 33012345 arrives kamailio decides on which server the conference takes place. For redundancy reasons I use the dispatcher again. If one of the server fails, another will take over the conferences. For the scenario with 2 servers this is trivial. There I also could do it another way. But when I add more conference servers it looks like the best solution to me. Here are my rules for the servers. In this case I used the policy "8" which should use the first destination according to the dispatcher.list file. So if I add more servers I can decide about a order for the fail over servers. route [ASTERISK_CONFERENCE] { if ($rU=~"(33[0-4][0-4][0-9][0-9][0-9][0-9]$)") { if ( method=="INVITE" ) { ds_select_dst("2","8"); forward(); exit(); } } if ($rU=~"(33[0-4][5-9][0-9][0-9][0-9][0-9]$)") { if ( method=="INVITE" ) { ds_select_dst("3","8"); forward(); exit(); } } } distpatcher.list # This group will be used with round robin for getting the room number 1 sip:172.16.1.88:5060 0 1 1 sip:172.16.1.89:5060 0 2 # failover schedule for ast-conf1 2 sip:172.16.1.88:5060 0 1 2 sip:172.16.1.89:5060 0 2 # failover schedule for ast-conf2 3 sip:172.16.1.89:5060 0 1 3 sip:172.16.1.88:5060 0 2 My current problem is, that the policy "8" don't select the other server in case of an failure. I simply blocks and the clients retransmit the request to kamailio.I am currently going crazy with that. :) When I change the policy to round robin (replacing "8" with "4"), everything is working fine. But this an option because in the normal case all calls to a conference room should be placed on the same server. Could this be a bug or something like that? Maybe not the right list here, but I didn't find anything about meetme implementation with more that one server or a HA/LB solution for that and was really wondering about that. Somebody maybe heart from such a implementation? Kind Regards, Sören Berger -- Dipl.-Inf. Sören Berger Rechenzentrum Universität Stuttgart Allmandring 30 70550 Stuttgart soeren.berger(a)rus.uni-stuttgart.de +49-(0)711-685-65871

2 3

New developer: Timo Teräs
by Daniel-Constantin Mierla 11 Apr '11

11 Apr '11

Hello, just to let everyone know that I grnted developer access to Timo, who submitted recently a patch for adding a new module named db_sqlite. As the name suggests, the new module will allot to use SQLite databases as alternative to existing db drivers such as mysql, postgres, a.s.o. Timo will maintain the new module and may help with other modules, as he previously submitted a patch for uac module. His GIT username for commits is: tteras. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

3 2

is_from_user_enum and SRV records
by Eric Hiller 11 Apr '11

11 Apr '11

We have enum records where 0123456789 points to 0123456789(a)domain.tld. And then multiple SRV records pointing to the actual hosts; _sip._udp SRV record for domain.tld pointing to host1.domain.tld and host2.domain.tld for load balancing. In our config we run is_from_user_enum, which up until adding a second entry for the SRV records worked fine. Now however the is_from_user_enum lookup invariably returns the opposite DNS record for the reply. Ie. host1 is requesting and the dns cache returns host2 and then the is_from_user_enum fails and the reply is dropped. Is there a way to make is_from_user_enum test ALL values of the SRV record? Thanks! -Eric

2 1

Kamailio multihoming
by roman＠dmytriv.com 11 Apr '11

11 Apr '11

Hello everybody!!! J Did any of you know or have configured Kamailio servers in redundant and load distribution mode on geographically dispersed servers. Can you share some ideas how can this be done. I'm thinking about 2 -3 servers that can be used to distribute load and for redundancy as well. Is Kamailio capable of this or this needs to be done on OS level. Thank you Roman

2 3

Re: [SR-Users] Kamailio XCAP for Kamailio IMS
by Daniel-Constantin Mierla 08 Apr '11

08 Apr '11

Hello, can you run kamailio with global parameter 'debug=3' and send the syslog messages for such case? That will give the hints about what is going wrong there. I see some characters are hexa encoded, but better see first the logs. Cheers, Daniel On 4/8/11 11:14 AM, Pavel Segeč wrote: > > Hi, > > I'm using Kamailio SIMPLE AS server as the presence and XCAP solution > as the extension for my Kamailio based IMS platfom. As the base > Presence configuration i'm using the default config as is described > inside of the tutorial from ASIPTO site, it works well for pure ietf > SIP SIMPLE environment. But when using it with the IMS, I sniff during > putting the new record 500 Error. May somebody show me a direction > what should be wrong? > > thanks > > palo > > PUT > /xcap-root/resource-lists/users/palo/index/~~/resource-lists/list%5B@name=%22doubango%22%5D/entry%5B@uri=%22sip:segi@ims1.sip.uniza.sk%22%5D > HTTP/1.1 > > Host: 158.193.139.36:5060 > > Content-Length: 151 > > Connection: Keep-Alive > > User-Agent: XDM-client/OMA1.1 > > X-3GPP-Intended-Identity: palo > > Content-Type: application/xcap-el+xml > > <entry uri="sip:segi@ims1.sip.uniza.sk" > xmlns="urn:ietf:params:xml:ns:resource-lists"> > > <display-name>segi(a)ims1.sip.uniza.sk</display-name> > > </entry>HTTP/1.1 500 Server error > > Via: SIP/2.0/TCP 158.193.152.64:20735 > > Server: kamailio (3.1.2 (i386/linux)) > > Content-Length: 0 > > > > __________ Informacia od ESET NOD32 Antivirus, verzia databazy 6025 > (20110408) __________ > > Tuto spravu preveril ESET NOD32 Antivirus. > > http://www.eset.sk > > > _______________________________________________ > 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 2

ring_insert_callid() fixup error
by Juha Heinanen 08 Apr '11

08 Apr '11

i have modparam("siputils", "ring_timeout", 30) but i get Apr 8 15:32:02 sip /usr/sbin/sip-proxy[23748]: ERROR: siputils [ring.c:378]: ring_insert_callid functionality deactivated, you need to set a positive ring_timeout Apr 8 15:32:02 sip /usr/sbin/sip-proxy[23748]: ERROR: <core> [route.c:1216]: fixing failed (code=-1) at cfg:/etc/sip-proxy/sip-proxy.cfg:658 Apr 8 15:32:02 sip /usr/sbin/sip-proxy[23748]: ERROR: <core> [route.c:1216]: fixing failed (code=-1) at cfg:/etc/sip-proxy/sip-proxy.cfg:691 when i start sip router (master version). i looked the code briefly and it tests module param value in fixup function, which i have not seen before. is this a bug or am i missing something? -- juha

2 3

Kamailio and several Asterisk - Realtime DB Integration
by Alejandro Rios P. 08 Apr '11

08 Apr '11

Hi all, I am testing the scenario described here: http://kb.asipto.com/asterisk:realtime:kamailio-3.1.x-asterisk-1.6.2-astdb It works great with one instance of Asterisk, but now that I'm testing with two Asterisk instances to load balance, and I see a problem regarding the registration forwarding to the second Asterisk. I tried adding a second "uac_req_send()" bellow the first one, but Kamailio only sends the first request and the REGISTER never gets to the second Asterisk: # Forward REGISTER to Asterisk route[REGFWD] { if(!is_method("REGISTER")) { return; } $var(rip) = $sel(cfg_get.asterisk.bindip); $uac_req(method)="REGISTER"; $uac_req(ruri)="sip:" + $var(rip) + ":" + $sel(cfg_get.asterisk.bindport); $uac_req(furi)="sip:" + $au + "@" + $var(rip); $uac_req(turi)="sip:" + $au + "@" + $var(rip); $uac_req(hdrs)="Contact: <sip:" + $au + "@" + $sel(cfg_get.kamailio.bindip) + ":" + $sel(cfg_get.kamailio.bindport) + ">\r\n"; if($sel(contact.expires) != $null) $uac_req(hdrs)= $uac_req(hdrs) + "Expires: " + $sel(contact.expires) + "\r\n"; else $uac_req(hdrs)= $uac_req(hdrs) + "Expires: " + $hdr(Expires) + "\r\n"; uac_req_send(); $uac_req(all) = null; $var(rip2) = $sel(cfg_get.asterisk2.bindip); $uac_req(method)="REGISTER"; $uac_req(ruri)="sip:" + $var(rip2) + ":" + $sel(cfg_get.asterisk2.bindport); $uac_req(furi)="sip:" + $au + "@" + $var(rip2); $uac_req(turi)="sip:" + $au + "@" + $var(rip2); $uac_req(hdrs)="Contact: <sip:" + $au + "@" + $sel(cfg_get.kamailio.bindip) + ":" + $sel(cfg_get.kamailio.bindport) + ">\r\n"; if($sel(contact.expires) != $null) $uac_req(hdrs)= $uac_req(hdrs) + "Expires: " + $sel(contact.expires) + "\r\n"; else $uac_req(hdrs)= $uac_req(hdrs) + "Expires: " + $hdr(Expires) + "\r\n"; uac_req_send(); } I also tried appending another branch and sending the second uac_req_send() from there, but it is not being sent. How can I use uac_req_send() several times for the same request or in parallel? Thank you, Alejandro Rios Peña DISCLAIMER: The opinions expressed are my own, and not necessarily those of my employer. <http://www.avatar.com.co>

2 1

SIP-XMPP problem, please help
by Martin Pohančeník 08 Apr '11

08 Apr '11

Hello everyone. I am a student at University of Žilina (Faculty of Management Science and Informatics), which has been recently awarded Kamailio 2010 Awards for various articles about SIP and KAMAILIO on portal nil.uniza.sk. I am doing a bachelor thesis on topic SIP/SIMPLE - XMPP traversal, but I am experiencing some problems. I have a working Kamailio server serving domain sip.uniza.sk and a working Jabberd2 server serving domain xmpp.uniza.sk. I am running Kamailio 3.1 with XMPP module with following configuration: fork=yes children=4 log_stderror=yes alias="sip.uniza.sk" ... loadmodule "XMPP.so" ... modparam("xmpp", "backend", "component") modparam("xmpp", "domain_separator", "*") modparam("xmpp", "gateway_domain", "sip.uniza.sk") modparam("xmpp", "xmpp_domain", "xmpp-sip.uniza.sk") modparam("xmpp", "xmpp_host", "server.xmpp.uniza.sk") modparam("xmpp", "xmpp_password", "secret") ... #main routing logic route { ... if( uri=~"sip:.+[*].+@sip.uniza.sk") { # absorb retransmissions ### if (!t_newtran()) { sl_reply_error(); return; } if (method == "MESSAGE") { log("*** xmpp-handled MESSAGE message.\n"); if (xmpp_send_message()) { t_reply("200", "Accepted"); } else { t_reply("404", "Not found"); } return; } else { t_reply("403","not supported"); exit; } } ... } To my knowledge there is no configuration required on the Jabberd2 server (except the password, that the XMPP component authenticates with). I am trying to enable SIP clients to chat with the XMPP clients and vice versa. SIP clients can send messages to XMPP clients. XMPP modules translates SIP to XMPP and forwards the massage to Jabberd2 server. URIs look like: XMPP client from SIP view: xmpp_client*xmpp.uniza.sk(a)sip.uniza.sk SIP client from XMPP view: sip_client*sip.uniza.sk(a)xmpp-sip.uniza.sk The message arrives to XMPP client, but he can not reply. I have sniffed the traffic on the Kamailio server. The XMPP message arrives to kamailio XMPP module (correct port and everything), but the module somehow ignores it, doesn't translate XMPP to SIP and doesn't send it to the SIP recipient. The sniffed message looks like: <message xmlns='jabber:client' type='chat' to='SIP_client*sip.uniza.sk@ xmpp-sip.uniza.sk' id='mir_47' from='XMPP_client(a)xmpp.uniza.sk/Miranda '><body>hello</body></message> Any suggestions on where can the problem be ?? Do I have to add some lines to routing logic for XMPP module to process the XMPP message (from Jabberd2) for SIP_client ?? Thanks Martin

3 5

TLS certificate on sip-router.org expired
by Timo Reimann 08 Apr '11

08 Apr '11

Heya, just noticed that the TLS certificate on sip-router.org has expired since 9.8.2010. Try an HTTPS connection to the web-page, i.e., https://sip-router.org to see. It seems to be self-signed though. Anyways, I just wanted to let you know. Cheers, --Timo

1 0

Kamailio XCAP for Kamailio IMS
by Pavel Segeč 08 Apr '11

08 Apr '11

Hi, I'm using Kamailio SIMPLE AS server as the presence and XCAP solution as the extension for my Kamailio based IMS platfom. As the base Presence configuration i'm using the default config as is described inside of the tutorial from ASIPTO site, it works well for pure ietf SIP SIMPLE environment. But when using it with the IMS, I sniff during putting the new record 500 Error. May somebody show me a direction what should be wrong? thanks palo PUT /xcap-root/resource-lists/users/palo/index/~~/resource-lists/list%5B@name=%2 2doubango%22%5D/entry%5B@uri=%22sip:segi@ims1.sip.uniza.sk%22%5D HTTP/1.1 Host: 158.193.139.36:5060 Content-Length: 151 Connection: Keep-Alive User-Agent: XDM-client/OMA1.1 X-3GPP-Intended-Identity: palo Content-Type: application/xcap-el+xml <entry uri="sip:segi@ims1.sip.uniza.sk" xmlns="urn:ietf:params:xml:ns:resource-lists"> <display-name>segi(a)ims1.sip.uniza.sk</display-name> </entry>HTTP/1.1 500 Server error Via: SIP/2.0/TCP 158.193.152.64:20735 Server: kamailio (3.1.2 (i386/linux)) Content-Length: 0

1 0

Problems with event_route[htable:mod-init]
by Camila Troncoso 07 Apr '11

07 Apr '11

Hello, I´m using Kamalio 3.1.0 and want to alter some databases (mysql) tables at kamailio starts. I read that the route event_route[htable:mod-init] allows me to do that, but i´m having some problems. I load htable.so module and insert the event_route[] in mi kamailio.conf script but when I start kamailio it returns an error: Apr 7 15:30:22 server4967 /usr/local/sbin/kamailio[31610]: DEBUG: <core> [sr_module.c:828]: DEBUG: init_mod_child (-127): usrloc Apr 7 15:30:22 server4967 /usr/local/sbin/kamailio[31610]: DEBUG: <core> [sr_module.c:828]: DEBUG: init_mod_child (-127): registrar Apr 7 15:30:22 server4967 /usr/local/sbin/kamailio[31610]: DEBUG: <core> [sr_module.c:828]: DEBUG: init_mod_child (-127): uri_db Apr 7 15:30:22 server4967 /usr/local/sbin/kamailio[31610]: DEBUG: <core> [sr_module.c:828]: DEBUG: init_mod_child (-127): domain Apr 7 15:30:22 server4967 /usr/local/sbin/kamailio[31610]: DEBUG: <core> [sr_module.c:828]: DEBUG: init_mod_child (-127): permissions Apr 7 15:30:22 server4967 /usr/local/sbin/kamailio[31610]: DEBUG: <core> [sr_module.c:828]: DEBUG: init_mod_child (-127): group Apr 7 15:30:22 server4967 /usr/local/sbin/kamailio[31610]: DEBUG: <core> [sr_module.c:828]: DEBUG: init_mod_child (-127): mi_fifo Apr 7 15:30:22 server4967 /usr/local/sbin/kamailio[31610]: DEBUG: <core> [sr_module.c:828]: DEBUG: init_mod_child (-127): avpops Apr 7 15:30:22 server4967 /usr/local/sbin/kamailio[31610]: DEBUG: <core> [sr_module.c:828]: DEBUG: init_mod_child (-127): dialog Apr 7 15:30:22 server4967 /usr/local/sbin/kamailio[31610]: DEBUG: <core> [sr_module.c:828]: DEBUG: init_mod_child (-127): lcr Apr 7 15:30:22 server4967 /usr/local/sbin/kamailio[31610]: DEBUG: <core> [sr_module.c:828]: DEBUG: init_mod_child (-127): sqlops Apr 7 15:30:22 server4967 /usr/local/sbin/kamailio[31610]: DEBUG: <core> [sr_module.c:828]: DEBUG: init_mod_child (-127): rtimer Apr 7 15:30:22 server4967 /usr/local/sbin/kamailio[31610]: DEBUG: <core> [sr_module.c:828]: DEBUG: init_mod_child (-127): htable Apr 7 15:30:22 server4967 /usr/local/sbin/kamailio[31610]: DEBUG: htable [htable.c:185]: rank is (-127) Apr 7 15:30:22 server4967 /usr/local/sbin/kamailio[31610]: DEBUG: htable [htable.c:191]: executing event_route[htable:mod-init] (1) Apr 7 15:30:22 server4967 /usr/local/sbin/kamailio[31610]: DEBUG: <core> [parser/msg_parser.c:630]: SIP Request: Apr 7 15:30:22 server4967 /usr/local/sbin/kamailio[31610]: DEBUG: <core> [parser/msg_parser.c:632]: method: <OPTIONS> Apr 7 15:30:22 server4967 /usr/local/sbin/kamailio[31610]: DEBUG: <core> [parser/msg_parser.c:634]: uri: <sip:you@kamailio.org> Apr 7 15:30:22 server4967 /usr/local/sbin/kamailio[31610]: DEBUG: <core> [parser/msg_parser.c:636]: version: <SIP/2.0> Apr 7 15:30:22 server4967 /usr/local/sbin/kamailio[31610]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bbfa0, 32) called from <core>: parser/msg_parser.c: parse_headers(341) Apr 7 15:30:22 server4967 /usr/local/sbin/kamailio[31610]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bbfa0, 32) returns address 0x834f780 frag. 0x834f768 (size=32) on 1 -th hit Apr 7 15:30:22 server4967 /usr/local/sbin/kamailio[31610]: <core> [mem/q_malloc.c:366]: qm_malloc(0x82bbfa0, 116) called from <core>: parser/msg_parser.c: get_hdr_field(130) Apr 7 15:30:22 server4967 /usr/local/sbin/kamailio[31610]: <core> [mem/q_malloc.c:406]: qm_malloc(0x82bbfa0, 116) returns address 0x834f7d0 frag. 0x834f7b8 (size=116) on 1 -th hit Apr 7 15:30:22 server4967 /usr/local/sbin/kamailio[31610]: DEBUG: <core> [parser/parse_via.c:2300]: end of header reached, state=2 Apr 7 15:30:22 server4967 /usr/local/sbin/kamailio[31610]: DEBUG: <core> [parser/msg_parser.c:515]: parse_headers: Via found, flags=2 Apr 7 15:30:22 server4967 /usr/local/sbin/kamailio[31610]: DEBUG: <core> [parser/msg_parser.c:517]: parse_headers: this is the first via Apr 7 15:30:22 server4967 kamailio: ERROR: <core> [daemonize.c:307]: Main process exited before writing to pipe * * * * My event_rout[] is as fallows: event_route[htable:mod-init]{ sql_query("cd", "select prefix from lcr_rule", "rc"); xlog("L_INFO", "dbr = $dbr(rc=>rows)"); if($dbr(rc=>rows)>0){ $var(i) = 0; while($var(i)<$dbr(rc=>rows)){ $var(prefijo)=$dbr(rc=>[$var(i),0]); xlog("L_INFO", "$dbr(rc=>[$var(i),0])"); sql_query("cd", "ALTER TABLE rebalse ADD COLUMN Prefijo_$var(prefijo) INT","rr"); $var(i) = $var(i) + 1; } } sql_result_free("rc"); } I tested the commands inside the event_route[] and they work fine… Can someone help me? Regards, *Camila Troncoso **|* Ingeniero de Desarrollo RedVoiss *|*ctroncoso(a)redvoiss.net Santiago - Chile *|* +56 2 2408535 www.redvoiss.net

2 1

It's ClueCon Time!
by marketing＠cluecon.com 07 Apr '11

07 Apr '11

1 0

"kamctl fifo debug" does not work
by Klaus Darilion 07 Apr '11

07 Apr '11

root@pbx-kam-1:/home/klaus3000# kamctl fifo debug DEBUG:: 2 root@pbx-kam-1:/home/klaus3000# kamctl fifo debug 0 DEBUG:: 0 Mar 9 11:04:23 pbx-kam-1 /usr/sbin/kamailio[4548]: INFO: <core> [cfg/cfg_ctx.c:411]: INFO: cfg_set_now(): core.debug has been changed to 0 but: root@pbx-kam-1:/home/klaus3000# kamctl fifo debug DEBUG:: 2 Is this a bug? regards Klaus

2 2

Kamailio at Google Summer of Code 2011
by Daniel-Constantin Mierla 07 Apr '11

07 Apr '11

Hello, for the second year, Kamailio is participating in GSoC program. For 2011, the proposal is to implement a signaling gateway between SIP and JINGLE to enable voice calls between the two networks: http://www.jitsi.org/index.php/GSOC2011/KamailioJingle If you are a student, or you know a student, interested in this project, just write me or to sr-dev(a)lists.sip-router.org. The application starts today and the deadline is April 8, therefore it is quite a short period, you will have to hurry. You can read more about the GSoC program and Kamailio at: http://www.kamailio.org/w/gsoc-2011/ http://www.jitsi.org/index.php/Development/Gsoc2011 Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

7 15

Cannot run Kamailio on public IP
by spamasbl＠gmail.com 07 Apr '11

07 Apr '11

Hello all, I have installed latest Kamailio 3.1.3 on latest ubuntu server. Everything seems to be working well on my LAN. I can successfully register with local Kamailio IP address (192.168.1.137). The issue is that I can not run Kamailio on my public IP: listen=udp:77.XX.XX.XX:5060 listen=udp:192.168.1.137:5060 port=5060 Kamailio runs behind Linksys WRT54GL router with latest Linksys firmware and DMZ is turned on (192.168.1.137). Here is the error I am getting when trying to run kamailio with my public IP: Apr 7 02:57:40 sipbox kamailio[1050]: ERROR: <core> [udp_server.c:400]: ERROR: udp_init: bind(7, 0x82cc6e4, 16) on 77.XX.XX.XX: Cannot assign requested address Do you have any idea what I'm doing wrong ? Thanks !

6 10

off-topic: jobs & projects - figuring out the best solution
by Daniel-Constantin Mierla 06 Apr '11

06 Apr '11

Hello, recently the demand in jobs and projects related to kamailio seemed to increase. I can just say that I am very happy with that. While announcing on the mailing lists is ok, I think we should try to make the process better and more productive, i.e., easier to advertise by publishers and easier to read for those interesting. For that, imo, we need a web page where someone can post such announcements and the others can read it. Since I had this idea in mind for some while, I searched for a dokuwiki plugin that could help, so we can reuse our wiki system. I found bureaucracy plugin, but does not seem to be ready for latest dokuwiki version according to its page: http://www.dokuwiki.org/plugin:bureaucracy But maybe it just works, I should try it instead of waiting, anyhow spare time is not my friend these days... Alternatives would be: - a wordpress plugin - haven't searched for one yet, but there are tons of plugins for WP, maybe one will fit the needs - another web application designed for such purposes My question to you is whether you can recommend a solution which we can evaluate. Ideally (or better said, as many characteristics to be met as possible), the system should be able to: - allow people to post announcements for jobs and projects (with or without prior registration, but with spam prevention - e.g., captcha) - allow to publish details about the job/projects, contact addresses, validity period - allow to invalidate an announcement when the position/project is taken - send an email notification when the announcement is done first time, with a link to the web page of the announcement, so we can send it one to a particular mailing list Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

4 3

job offer: System administrator internet access services
by Henning Westerholt 06 Apr '11

06 Apr '11

Job offer: Interested in working with one of the biggest Voice over IP networks in europe? We're hiring and have one additional IT operation position open in our team in Karlsruhe, Germany at the moment. You would be responsible in a team of motivated system administrators for the operation and maintenance of the radius and CPE auto-provisioning services at 1&1. Furthermore you would support our on-call service for all the services operated from the team, including VoIP. A solid understanding of german is necessary for the job, for more informations (additional requirements, how to apply..) please refer to the opening on the job web page. Of course please feel free to contact me per mail as well. http://www.united-internet.de/JobsJobDetail?__sendingdata=1&JobDetails.jobI… Best regards, Henning Westerholt -- Henning Westerholt - Head of IT Operations Internet Access & Communications 1&1 Internet AG, Brauerstraße 48, 76135 Karlsruhe, Germany

1 0

Re: [SR-Users] Kamailio ims / rtpproxy
by Carsten Bock 06 Apr '11

06 Apr '11

Hi, the Kamailio IMS modules are based on the OpenIMSCore-CSCF modules, which have built-in RTPProxy support. I am working on replacing the built-in RTPProxy support in the CSCF modules with the "original" rtpproxy-module of the Kamailio/sip-router.org. It does depend on your config, which RTPProxy support you use.... (but the focus is currently on other parts, be patient). Carsten 2011/4/6 Pavel Segeč <Pavel.Segec(a)fri.uniza.sk>: > Hi, > > I do not understand, may you clarify it? I'm using Kamailio based PCSCF not OIMSC, and kamailio has rtpproxy module...should I'm able to build PCSCF using sip router? > > palo > >> -----Original Message----- >> From: Carsten Bock [mailto:carsten@ng-voice.com] >> Sent: Wednesday, April 06, 2011 11:30 AM >> To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users >> Mailing List >> Cc: Pavel Segeč >> Subject: Re: [SR-Users] Kamailio ims / rtpproxy >> >> Hi, >> >> one reason more to replace the built-in RTP-Proxy support of the CSCF >> with the "real" rtpproxy moduie of sip-router.org! ;-) >> >> Carsten >> >> 2011/4/6 Pavel Segeč <Pavel.Segec(a)fri.uniza.sk>: >> > Hi Carsten, >> > >> > Thank you for answer. I did it as you described (anyway, i think, that >> nat traversal is by default on), but there were still some problems. >> After some deeper testing, the PCSCF with RTPproxy works well with two >> Monster client (caller and calle). The problem is with Boghe IMS >> clients, I do not know why, private address inside of the SDP is not >> rewritten, what is interesting, media ports are changing. >> > >> > regards >> > >> > palo >> > >> >> -----Original Message----- >> >> From: sr-users-bounces(a)lists.sip-router.org [mailto:sr-users- >> >> bounces(a)lists.sip-router.org] On Behalf Of Carsten Bock >> >> Sent: Wednesday, April 06, 2011 10:32 AM >> >> To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - >> Users >> >> Mailing List >> >> Cc: Pavel Segeč >> >> Subject: Re: [SR-Users] Kamailio ims / rtpproxy >> >> >> >> Hi, >> >> >> >> there is no documentation on the RTPProxy interface of the Kamailio >> >> IMS module yet. >> >> You need to have the following linse in the Kamailio.cfg: >> >> >> >> # Enabled Features on this host: >> >> #!define WITH_NAT >> >> [...] >> >> #!ifdef WITH_NAT >> >> #!define RTPPROXY "udp:127.0.0.1:22222" >> >> #!endif >> >> [...] >> >> #!ifndef WITH_NAT >> >> [...] >> >> #!else >> >> modparam("pcscf","NAT_enable", 1) >> >> modparam("pcscf","ping", 1) >> >> modparam("pcscf","ping_all", 0) >> >> modparam("pcscf","nat_detection_type", 0x17) >> >> modparam("pcscf","rtpproxy_socket", RTPPROXY) >> >> modparam("pcscf","rtpproxy_enable", 1) >> >> modparam("pcscf","rtpproxy_disable_tout", 60) >> >> modparam("pcscf","rtpproxy_retr", 5) >> >> modparam("pcscf","rtpproxy_tout", 1) >> >> #!endif >> >> >> >> Kind regards, >> >> Carsten >> >> >> >> 2011/4/5 Pavel Segeč <pavel.segec(a)fri.uniza.sk>: >> >> > Hi, >> >> > >> >> > >> >> > >> >> > I would like ask you if there is a kamailio ims module >> documentation >> >> > somewhere. I need some deeper information how some things are >> >> implemented, I >> >> > have problem to setup NAT traversal with RTPproxy for our Kamailio >> IMS >> >> > platform. There is no communication among the PCSCF and RTPproxy >> >> server over >> >> > control udp sock. We tried unix socket also with the same results. >> >> > >> >> > >> >> > >> >> > Thanks >> >> > >> >> > >> >> > >> >> > palo73 >> >> > >> >> > http://nil.uniza.sk >> >> > >> >> > __________ Informacia od ESET NOD32 Antivirus, verzia databazy 6016 >> >> > (20110405) __________ >> >> > >> >> > Tuto spravu preveril ESET NOD32 Antivirus. >> >> > >> >> > http://www.eset.sk >> >> > >> >> > _______________________________________________ >> >> > 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 >> >> > >> >> > >> >> >> >> >> >> >> >> -- >> >> Carsten Bock >> >> http://www.ng-voice.com >> >> mailto:carsten@ng-voice.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 >> >> >> >> >> >> __________ Informacia od ESET NOD32 Antivirus, verzia databazy 6017 >> >> (20110405) __________ >> >> >> >> Tuto spravu preveril ESET NOD32 Antivirus. >> >> >> >> http://www.eset.sk >> >> >> > >> > >> > __________ Informacia od ESET NOD32 Antivirus, verzia databazy 6017 >> (20110405) __________ >> > >> > Tuto spravu preveril ESET NOD32 Antivirus. >> > >> > http://www.eset.sk >> > >> > >> > >> > _______________________________________________ >> > 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 >> > >> >> >> >> -- >> Carsten Bock >> http://www.ng-voice.com >> mailto:carsten@ng-voice.com >> >> Schomburgstr. 80 >> 22767 Hamburg >> Germany >> >> Mobile +49 179 2021244 >> Office +49 40 34927219 >> Fax +49 40 34927220 >> >> >> __________ Informacia od ESET NOD32 Antivirus, verzia databazy 6017 >> (20110405) __________ >> >> Tuto spravu preveril ESET NOD32 Antivirus. >> >> http://www.eset.sk >> > > > __________ Informacia od ESET NOD32 Antivirus, verzia databazy 6017 (20110405) __________ > > Tuto spravu preveril ESET NOD32 Antivirus. > > http://www.eset.sk > > > > _______________________________________________ > 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 > -- Carsten Bock http://www.ng-voice.com mailto:carsten@ng-voice.com

3 5

Re: [SR-Users] Kamailio ims / rtpproxy
by Alex Balashov 06 Apr '11

06 Apr '11

On 04/06/2011 05:48 AM, Pavel Segeč wrote: > I do not understand, may you clarify it? I'm using Kamailio based > PCSCF not OIMSC, and kamailio has rtpproxy module...should I'm able > to build PCSCF using sip router? Don't worry about this. This is a reference to an ongoing bit of development esoterica related to the fact that Kamailio already has--and has had for a very long time--a module to control rtpproxy. It is not part of the IMS module framework Carsten is developing. -- Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/

1 0

Re: [SR-Users] Kamailio ims / rtpproxy
by Carsten Bock 06 Apr '11

06 Apr '11

Hi, one reason more to replace the built-in RTP-Proxy support of the CSCF with the "real" rtpproxy moduie of sip-router.org! ;-) Carsten 2011/4/6 Pavel Segeč <Pavel.Segec(a)fri.uniza.sk>: > Hi Carsten, > > Thank you for answer. I did it as you described (anyway, i think, that nat traversal is by default on), but there were still some problems. After some deeper testing, the PCSCF with RTPproxy works well with two Monster client (caller and calle). The problem is with Boghe IMS clients, I do not know why, private address inside of the SDP is not rewritten, what is interesting, media ports are changing. > > regards > > palo > >> -----Original Message----- >> From: sr-users-bounces(a)lists.sip-router.org [mailto:sr-users- >> bounces(a)lists.sip-router.org] On Behalf Of Carsten Bock >> Sent: Wednesday, April 06, 2011 10:32 AM >> To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users >> Mailing List >> Cc: Pavel Segeč >> Subject: Re: [SR-Users] Kamailio ims / rtpproxy >> >> Hi, >> >> there is no documentation on the RTPProxy interface of the Kamailio >> IMS module yet. >> You need to have the following linse in the Kamailio.cfg: >> >> # Enabled Features on this host: >> #!define WITH_NAT >> [...] >> #!ifdef WITH_NAT >> #!define RTPPROXY "udp:127.0.0.1:22222" >> #!endif >> [...] >> #!ifndef WITH_NAT >> [...] >> #!else >> modparam("pcscf","NAT_enable", 1) >> modparam("pcscf","ping", 1) >> modparam("pcscf","ping_all", 0) >> modparam("pcscf","nat_detection_type", 0x17) >> modparam("pcscf","rtpproxy_socket", RTPPROXY) >> modparam("pcscf","rtpproxy_enable", 1) >> modparam("pcscf","rtpproxy_disable_tout", 60) >> modparam("pcscf","rtpproxy_retr", 5) >> modparam("pcscf","rtpproxy_tout", 1) >> #!endif >> >> Kind regards, >> Carsten >> >> 2011/4/5 Pavel Segeč <pavel.segec(a)fri.uniza.sk>: >> > Hi, >> > >> > >> > >> > I would like ask you if there is a kamailio ims module documentation >> > somewhere. I need some deeper information how some things are >> implemented, I >> > have problem to setup NAT traversal with RTPproxy for our Kamailio IMS >> > platform. There is no communication among the PCSCF and RTPproxy >> server over >> > control udp sock. We tried unix socket also with the same results. >> > >> > >> > >> > Thanks >> > >> > >> > >> > palo73 >> > >> > http://nil.uniza.sk >> > >> > __________ Informacia od ESET NOD32 Antivirus, verzia databazy 6016 >> > (20110405) __________ >> > >> > Tuto spravu preveril ESET NOD32 Antivirus. >> > >> > http://www.eset.sk >> > >> > _______________________________________________ >> > 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 >> > >> > >> >> >> >> -- >> Carsten Bock >> http://www.ng-voice.com >> mailto:carsten@ng-voice.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 >> >> >> __________ Informacia od ESET NOD32 Antivirus, verzia databazy 6017 >> (20110405) __________ >> >> Tuto spravu preveril ESET NOD32 Antivirus. >> >> http://www.eset.sk >> > > > __________ Informacia od ESET NOD32 Antivirus, verzia databazy 6017 (20110405) __________ > > Tuto spravu preveril ESET NOD32 Antivirus. > > http://www.eset.sk > > > > _______________________________________________ > 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 > -- Carsten Bock http://www.ng-voice.com mailto:carsten@ng-voice.com Schomburgstr. 80 22767 Hamburg Germany Mobile +49 179 2021244 Office +49 40 34927219 Fax +49 40 34927220

2 1

Re: [SR-Users] Kamailio ims / rtpproxy
by Carsten Bock 06 Apr '11

06 Apr '11

Hi, there is no documentation on the RTPProxy interface of the Kamailio IMS module yet. You need to have the following linse in the Kamailio.cfg: # Enabled Features on this host: #!define WITH_NAT [...] #!ifdef WITH_NAT #!define RTPPROXY "udp:127.0.0.1:22222" #!endif [...] #!ifndef WITH_NAT [...] #!else modparam("pcscf","NAT_enable", 1) modparam("pcscf","ping", 1) modparam("pcscf","ping_all", 0) modparam("pcscf","nat_detection_type", 0x17) modparam("pcscf","rtpproxy_socket", RTPPROXY) modparam("pcscf","rtpproxy_enable", 1) modparam("pcscf","rtpproxy_disable_tout", 60) modparam("pcscf","rtpproxy_retr", 5) modparam("pcscf","rtpproxy_tout", 1) #!endif Kind regards, Carsten 2011/4/5 Pavel Segeč <pavel.segec(a)fri.uniza.sk>: > Hi, > > > > I would like ask you if there is a kamailio ims module documentation > somewhere. I need some deeper information how some things are implemented, I > have problem to setup NAT traversal with RTPproxy for our Kamailio IMS > platform. There is no communication among the PCSCF and RTPproxy server over > control udp sock. We tried unix socket also with the same results. > > > > Thanks > > > > palo73 > > http://nil.uniza.sk > > __________ Informacia od ESET NOD32 Antivirus, verzia databazy 6016 > (20110405) __________ > > Tuto spravu preveril ESET NOD32 Antivirus. > > http://www.eset.sk > > _______________________________________________ > 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 > > -- Carsten Bock http://www.ng-voice.com mailto:carsten@ng-voice.com

2 1

[PATCH] modules_k/uac: fix from/to restore for small original URI
by Timo Teräs 06 Apr '11

06 Apr '11

Seems that the URI length check is superfluous and fails under certain conditions. It does not make sense for the URI to have zero bytes, so just use the first seen zero byte as end marker. I have a reproducible test case where the restore inserts URI with multiple zero-bytes to wire. This happens if the original URI is smaller than the one we rewrote it to using uac_replace_from. Signed-off-by: Timo Teräs <timo.teras(a)iki.fi> --- modules_k/uac/from.c | 14 ++++++++------ 1 files changed, 8 insertions(+), 6 deletions(-) However, I think the delta encoding used for the RR attribute is flawed. Hostile remote server could rewrite the RR attribute and/or From/To headers in a way to forge it to something it was not in the first place. Additionally the delta-encoded RR attribute breaks if the From/To header isn't exact copy of what we sent. Would it not make more sense to just send the real original header (possibly encrypted) but with a checksum? We could then verify if someone had clobbered the RR attribute and ignore it. And we could always restore the original URI even if the URI we are swapping was modified unexpectedly. diff --git a/modules_k/uac/from.c b/modules_k/uac/from.c index 4657e11..50822b6 100644 --- a/modules_k/uac/from.c +++ b/modules_k/uac/from.c @@ -463,15 +463,17 @@ int restore_from( struct sip_msg *msg, int *is_from ) LM_ERR("new URI shorter than old URI\n"); goto failed; } - for( i=0 ; i<old_uri.len ; i++ ) + for( i=0 ; i<old_uri.len ; i++ ) { new_uri.s[i] ^= old_uri.s[i]; - if (new_uri.len==old_uri.len) { - for( ; new_uri.len && (new_uri.s[new_uri.len-1]==0) ; new_uri.len-- ); - if (new_uri.len==0) { - LM_ERR("new URI got 0 len\n"); - goto failed; + if (new_uri.s[i] == 0) { + new_uri.len = i; + break; } } + if (new_uri.len==0) { + LM_ERR("new URI got 0 len\n"); + goto failed; + } LM_DBG("decoded uris are: new=[%.*s] old=[%.*s]\n", new_uri.len, new_uri.s, old_uri.len, old_uri.s); -- 1.7.1

2 1

Custom voicemail table
by Lucas Alvarez 05 Apr '11

05 Apr '11

Hi, is it possible to change the name of the table voicemessages for voicemail profile in a kamailio-asterisk integration? I mean of the kamailio side. Thanks in advance. Lucas

2 2

Kamailio ims / rtpproxy
by Pavel Segeč 05 Apr '11

05 Apr '11

Hi, I would like ask you if there is a kamailio ims module documentation somewhere. I need some deeper information how some things are implemented, I have problem to setup NAT traversal with RTPproxy for our Kamailio IMS platform. There is no communication among the PCSCF and RTPproxy server over control udp sock. We tried unix socket also with the same results. Thanks palo73 http://nil.uniza.sk

1 0

Kamailio RPMs for v3.1.3
by Daniel-Constantin Mierla 05 Apr '11

05 Apr '11

Hello, the RPM packages for Kamailio recently released v3.1.3 are now available for CentOS, Fedora, RedHat and OpenSUSE, available on the opensuse.org build service: * https://build.opensuse.org/package/show?package=kamailio&project=home%3Akam… <https://build.opensuse.org/package/show?package=kamailio&project=home%3Akam…> Specific 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… Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

1 0

Kamailio v3.1.3 Released
by Daniel-Constantin Mierla 05 Apr '11

05 Apr '11

Hello, Kamailio SIP Server v3.1.3 stable release is out. This is a maintenance release of latest stable branch, 3.1, that includes fixes since release of v3.1.2. There is no change to database schema or configuration language structure. Deployments running v3.1.0, v3.1.1 or 3.1.2 are strongly recommended to be upgraded to v3.1.3. For more details about version 3.1.3, visit: http://www.kamailio.org/w/2011/04/kamailio-v3-1-3-released/ Note: existing configuration files for installations on 64b operating systems may need to be updated to specify 'lib64' to the path where the modules are installed (to the value of parameter 'mpath'). See bottom note of the link provided above. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

3 3

tcp hangup
by Juha Heinanen 05 Apr '11

05 Apr '11

i have two sr proxies talking with each other over tcp. one is running 3.0 and the other 3.1. sometimes i notice that no sip requests or any other tcp packets get through from 3.0 sr host to 3.1 sr host. netstat on 3.0 sr host shows that tcp connection to 3.1 sr host is in ESTABLISHED state whereas netstat on 3.1 sr shows that the same tcp connection is in FIN_WAIT1 state. it takes several minutes before the hanging tcp connection is replaced by a new working one. there is no ip level connectivity problem between the two sr hosts. any suggestions on what might be going on? is there some known bug in 3.0 tcp implementation that could explain this? -- juha

3 12

[PATCH] modules_k/db_sqlite: new sql backend
by Timo Teräs 05 Apr '11

05 Apr '11

Implements the kamailio database API for SQLite. Signed-off-by: Timo Teräs <timo.teras(a)iki.fi> --- modules_k/db_sqlite/Makefile | 15 ++ modules_k/db_sqlite/db_sqlite.c | 90 +++++++ modules_k/db_sqlite/dbase.c | 515 +++++++++++++++++++++++++++++++++++++++ modules_k/db_sqlite/dbase.h | 72 ++++++ 4 files changed, 692 insertions(+), 0 deletions(-) create mode 100644 modules_k/db_sqlite/Makefile create mode 100644 modules_k/db_sqlite/db_sqlite.c create mode 100644 modules_k/db_sqlite/dbase.c create mode 100644 modules_k/db_sqlite/dbase.h diff --git a/modules_k/db_sqlite/Makefile b/modules_k/db_sqlite/Makefile new file mode 100644 index 0000000..9a75593 --- /dev/null +++ b/modules_k/db_sqlite/Makefile @@ -0,0 +1,15 @@ +# $Id$ +# +# WARNING: do not run this directly, it should be run by the master Makefile + +include ../../Makefile.defs +auto_gen= +NAME=db_sqlite.so + +LIBS +=-lsqlite3 + +DEFS+=-DOPENSER_MOD_INTERFACE + +SERLIBPATH=../../lib +SER_LIBS+=$(SERLIBPATH)/srdb1/srdb1 +include ../../Makefile.modules diff --git a/modules_k/db_sqlite/db_sqlite.c b/modules_k/db_sqlite/db_sqlite.c new file mode 100644 index 0000000..8ec16e3 --- /dev/null +++ b/modules_k/db_sqlite/db_sqlite.c @@ -0,0 +1,90 @@ +/* + * $Id$ + * + * SQlite module interface + * + * Copyright (C) 2010 Timo Teräs + * + * This file is part of Kamailio, a free SIP server. + * + * Kamailio is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version + * + * Kamailio is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#include <sys/time.h> +#include <sqlite3.h> + +#include "../../sr_module.h" +#include "../../lib/srdb1/db.h" +#include "dbase.h" + +MODULE_VERSION + +static int sqlite_bind_api(db_func_t *dbb) +{ + if(dbb==NULL) + return -1; + + memset(dbb, 0, sizeof(db_func_t)); + + dbb->use_table = db_sqlite_use_table; + dbb->init = db_sqlite_init; + dbb->close = db_sqlite_close; + dbb->free_result = db_sqlite_free_result; + dbb->query = db_sqlite_query; + dbb->insert = db_sqlite_insert; + dbb->delete = db_sqlite_delete; + dbb->update = db_sqlite_update; + dbb->raw_query = db_sqlite_raw_query; + + return 0; +} + +static cmd_export_t cmds[] = { + {"db_bind_api", (cmd_function)sqlite_bind_api, 0, 0, 0, 0}, + {0, 0, 0, 0, 0, 0} +}; + +static int sqlite_mod_init(void) +{ + sqlite3_initialize(); + + LM_INFO("SQlite library version %s (compiled using %s)\n", + sqlite3_libversion(), + SQLITE_VERSION); + return 0; +} + + +static void sqlite_mod_destroy(void) +{ + LM_INFO("SQlite terminate\n"); + + sqlite3_shutdown(); +} + +struct module_exports exports = { + "db_sqlite", + DEFAULT_DLFLAGS, /* dlopen flags */ + cmds, /* module commands */ + 0, /* module parameters */ + 0, /* exported statistics */ + 0, /* exported MI functions */ + 0, /* exported pseudo-variables */ + 0, /* extra processes */ + sqlite_mod_init, /* module initialization function */ + 0, /* response function*/ + sqlite_mod_destroy, /* destroy function */ + 0 /* per-child init function */ +}; diff --git a/modules_k/db_sqlite/dbase.c b/modules_k/db_sqlite/dbase.c new file mode 100644 index 0000000..b64b327 --- /dev/null +++ b/modules_k/db_sqlite/dbase.c @@ -0,0 +1,515 @@ +/* + * $Id$ + * + * SQlite module core functions + * + * Copyright (C) 2010 Timo Teräs + * + * This file is part of Kamailio, a free SIP server. + * + * Kamailio is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version + * + * Kamailio is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#include "../../mem/mem.h" +#include "../../dprint.h" +#include "../../lib/srdb1/db_pool.h" +#include "../../lib/srdb1/db_ut.h" +#include "../../lib/srdb1/db_res.h" +#include "../../lib/srdb1/db_query.h" +#include "dbase.h" + +static time_t sqlite_to_timet(double rT) +{ + return 86400.0*(rT - 2440587.5) + 0.5; +} + +static double timet_to_sqlite(time_t t) +{ + return ((((double) t) - 0.5) / 86400.0) + 2440587.5; +} + +/* + * Initialize database module + * No function should be called before this + */ + +static struct sqlite_connection * db_sqlite_new_connection(const struct db_id* id) +{ + struct sqlite_connection *con; + int rc; + + con = pkg_malloc(sizeof(*con)); + if (!con) { + LM_ERR("failed to allocate driver connection\n"); + return NULL; + } + + memset(con, 0, sizeof(*con)); + con->hdr.ref = 1; + con->hdr.id = (struct db_id*) id; /* set here - freed on error */ + + rc = sqlite3_open_v2(id->database, &con->conn, + SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE, NULL); + if (rc != SQLITE_OK) { + pkg_free(con); + LM_ERR("failed to open sqlite database '%s'\n", id->database); + return NULL; + } + + return con; +} + +db1_con_t* db_sqlite_init(const str* _url) +{ + return db_do_init(_url, (void *) db_sqlite_new_connection); +} + + +/* + * Shut down database module + * No function should be called after this + */ + +static void db_sqlite_free_connection(struct sqlite_connection* con) +{ + if (!con) return; + + sqlite3_close(con->conn); + free_db_id(con->hdr.id); + pkg_free(con); +} + +void db_sqlite_close(db1_con_t* _h) +{ + db_do_close(_h, db_sqlite_free_connection); +} + +/* + * Release a result set from memory + */ +int db_sqlite_free_result(db1_con_t* _h, db1_res_t* _r) +{ + if (!_h || !_r) { + LM_ERR("invalid parameter value\n"); + return -1; + } + + if (db_free_result(_r) < 0) + { + LM_ERR("failed to free result structure\n"); + return -1; + } + return 0; +} + +/* + * Store name of table that will be used by + * subsequent database functions + */ +int db_sqlite_use_table(db1_con_t* _h, const str* _t) +{ + return db_use_table(_h, _t); +} + +/* + * Reset query context + */ +static void db_sqlite_cleanup_query(const db1_con_t* _c) +{ + struct sqlite_connection *conn = CON_SQLITE(_c); + int rc; + + if (conn->stmt != NULL) { + rc = sqlite3_finalize(conn->stmt); + if (rc != SQLITE_OK) + LM_ERR("finalize failed: %s\n", + sqlite3_errmsg(conn->conn)); + } + + conn->stmt = NULL; + conn->bindpos = 0; +} + +/* + * Convert value to sql-string as db bind index + */ +static int db_sqlite_val2str(const db1_con_t* _c, const db_val_t* _v, char* _s, int* _len) +{ + struct sqlite_connection *conn; + int ret; + + if (!_c || !_v || !_s || !_len || *_len <= 0) { + LM_ERR("invalid parameter value\n"); + return -1; + } + + conn = CON_SQLITE(_c); + if (conn->bindpos >= DB_SQLITE_MAX_BINDS) { + LM_ERR("too many bindings, recompile with larger DB_SQLITE_MAX_BINDS\n"); + return -2; + } + + conn->bindarg[conn->bindpos] = _v; + ret = snprintf(_s, *_len, "?%u", ++conn->bindpos); + if ((unsigned)ret >= (unsigned) *_len) + return -11; + + *_len = ret; + return 0; +} + +/* + * Send an SQL query to the server + */ +static int db_sqlite_submit_query(const db1_con_t* _h, const str* _s) +{ + struct sqlite_connection *conn = CON_SQLITE(_h); + sqlite3_stmt *stmt; + const db_val_t *val; + int rc, i; + + LM_DBG("submit_query: %.*s\n", _s->len, _s->s); + + rc = sqlite3_prepare_v2(conn->conn, _s->s, _s->len, &stmt, NULL); + if (rc != SQLITE_OK) { + LM_ERR("failed to prepare statement: %s\n", + sqlite3_errmsg(conn->conn)); + return -1; + } + conn->stmt = stmt; + + for (i = 1; i <= conn->bindpos; i++) { + val = conn->bindarg[i-1]; + if (VAL_NULL(val)) { + rc = sqlite3_bind_null(stmt, i); + } else switch (VAL_TYPE(val)) { + case DB1_INT: + rc = sqlite3_bind_int(stmt, i, VAL_INT(val)); + break; + case DB1_BIGINT: + rc = sqlite3_bind_int64(stmt, i, VAL_BIGINT(val)); + break; + case DB1_DOUBLE: + rc = sqlite3_bind_double(stmt, i, VAL_DOUBLE(val)); + break; + case DB1_STRING: + rc = sqlite3_bind_text(stmt, i, + VAL_STRING(val), -1, NULL); + break; + case DB1_STR: + rc = sqlite3_bind_text(stmt, i, + VAL_STR(val).s, VAL_STR(val).len, NULL); + break; + case DB1_DATETIME: + rc = sqlite3_bind_double(stmt, i, timet_to_sqlite(VAL_TIME(val))); + break; + case DB1_BLOB: + rc = sqlite3_bind_blob(stmt, i, + VAL_BLOB(val).s, VAL_BLOB(val).len, + NULL); + break; + case DB1_BITMAP: + rc = sqlite3_bind_int(stmt, i, VAL_BITMAP(val)); + break; + default: + LM_ERR("unknown bind value type %d\n", VAL_TYPE(val)); + return -1; + } + if (rc != SQLITE_OK) { + LM_ERR("Parameter bind failed: %s\n", + sqlite3_errmsg(conn->conn)); + return -1; + } + } + + return 0; +} + +static int decltype_to_dbtype(const char *decltype) +{ + /* SQlite3 has dynamic typing. It does not store the actual + * exact type, instead it uses 'affinity' depending on the + * value. We have to go through the declaration types to see + * what to return. */ + if (strstr(decltype, "INT") != NULL || + strncasecmp(decltype, "SERIAL", 6) == 0) + return DB1_INT; + if (strstr(decltype, "CHAR") != NULL) + return DB1_STRING; + if (strstr(decltype, "TEXT") != NULL) + return DB1_STR; + if (strstr(decltype, "REAL") != NULL || + strstr(decltype, "FLOA") != NULL || + strstr(decltype, "DOUB") != NULL) + return DB1_DOUBLE; + if (strstr(decltype, "BLOB") != NULL) + return DB1_BLOB; + if (strncasecmp(decltype, "TIME", 4) == 0 || + strncasecmp(decltype, "DATE", 4) == 0) + return DB1_DATETIME; + + LM_ERR("sqlite decltype '%s' not recognized, defaulting to int", + decltype); + return DB1_INT; +} + +static str* str_dup(const char *_s) +{ + str *s; + int len = strlen(_s); + + s = (str*) pkg_malloc(sizeof(str)+len+1); + s->len = len; + s->s = ((char*)s) + sizeof(str); + memcpy(s->s, _s, len); + s->s[len] = '\0'; + + return s; +} + +static void str_assign(str* s, const char *_s, int len) +{ + s->s = (char *) pkg_malloc(len + 1); + s->len = len; + memcpy(s->s, _s, len); + s->s[len] = 0; +} + +/* + * Read database answer and fill the structure + */ +int db_sqlite_store_result(const db1_con_t* _h, db1_res_t** _r) +{ + struct sqlite_connection *conn = CON_SQLITE(_h); + db1_res_t *res; + int i, rc, num_rows = 0, num_alloc = 0; + db_row_t *rows = NULL, *row; + db_val_t *val; + + res = db_new_result(); + if (res == NULL) + goto no_mem; + + while (1) { + rc = sqlite3_step(conn->stmt); + if (rc == SQLITE_DONE) { + *_r = res; + return 0; + } + if (rc != SQLITE_ROW) { + LM_INFO("sqlite3_step failed: %s\n", sqlite3_errmsg(conn->conn)); + goto err; + } + if (num_rows == 0) { + /* get column types */ + rc = sqlite3_column_count(conn->stmt); + if (db_allocate_columns(res, rc) != 0) + goto err; + RES_COL_N(res) = rc; + + for (i = 0; i < RES_COL_N(res); i++) { + RES_NAMES(res)[i] = str_dup(sqlite3_column_name(conn->stmt, i)); + RES_TYPES(res)[i] = decltype_to_dbtype(sqlite3_column_decltype(conn->stmt, i)); + } + } + if (num_rows >= num_alloc) { + if (num_alloc) + num_alloc *= 2; + else + num_alloc = 8; + rows = pkg_realloc(rows, sizeof(db_row_t) * num_alloc); + if (rows == NULL) + goto no_mem; + RES_ROWS(res) = rows; + } + + row = &RES_ROWS(res)[num_rows]; + num_rows++; + RES_ROW_N(res) = num_rows; /* rows in this result set */ + RES_NUM_ROWS(res) = num_rows; /* rows in total */ + + if (db_allocate_row(res, row) != 0) + goto no_mem; + + for (i = 0, val = ROW_VALUES(row); i < RES_COL_N(res); i++, val++) { + VAL_TYPE(val) = RES_TYPES(res)[i]; + VAL_NULL(val) = 0; + VAL_FREE(val) = 0; + if (sqlite3_column_type(conn->stmt, i) == SQLITE_NULL) { + VAL_NULL(val) = 1; + } else switch (VAL_TYPE(val)) { + case DB1_INT: + VAL_INT(val) = sqlite3_column_int(conn->stmt, i); + break; + case DB1_BIGINT: + VAL_BIGINT(val) = sqlite3_column_int64(conn->stmt, i); + break; + case DB1_STRING: + /* first field of struct str* is the char* so we can just + * do whatever DB1_STR case does */ + case DB1_STR: + str_assign(&VAL_STR(val), + (const char*) sqlite3_column_text(conn->stmt, i), + sqlite3_column_bytes(conn->stmt, i)); + VAL_FREE(val) = 1; + break; + case DB1_DOUBLE: + VAL_DOUBLE(val) = sqlite3_column_double(conn->stmt, i); + break; + case DB1_DATETIME: + VAL_TIME(val) = sqlite_to_timet(sqlite3_column_double(conn->stmt, i)); + break; + case DB1_BLOB: + str_assign(&VAL_BLOB(val), + (const char*) sqlite3_column_blob(conn->stmt, i), + sqlite3_column_bytes(conn->stmt, i)); + VAL_FREE(val) = 1; + break; + default: + LM_ERR("unhandled db-type\n"); + goto err; + } + } + } + +no_mem: + LM_ERR("no private memory left\n"); +err: + if (res) + db_free_result(res); + return -1; +} + +/* + * Query table for specified rows + * _h: structure representing database connection + * _k: key names + * _op: operators + * _v: values of the keys that must match + * _c: column names to return + * _n: number of key=values pairs to compare + * _nc: number of columns to return + * _o: order by the specified column + */ +int db_sqlite_query(const db1_con_t* _h, const db_key_t* _k, const db_op_t* _op, + const db_val_t* _v, const db_key_t* _c, int _n, int _nc, + const db_key_t _o, db1_res_t** _r) +{ + int rc; + + rc = db_do_query(_h, _k, _op, _v, _c, _n, _nc, _o, _r, + db_sqlite_val2str, + db_sqlite_submit_query, + db_sqlite_store_result); + db_sqlite_cleanup_query(_h); + + return rc; +} + +static int db_sqlite_commit(const db1_con_t* _h) +{ + struct sqlite_connection *conn = CON_SQLITE(_h); + int rc; + + rc = sqlite3_step(conn->stmt); + if (rc != SQLITE_DONE && rc != SQLITE_OK) { + LM_ERR("sqlite commit failed: %s\n", + sqlite3_errmsg(conn->conn)); + return -1; + } + + return 0; +} + +/* + * Insert a row into specified table + * _h: structure representing database connection + * _k: key names + * _v: values of the keys + * _n: number of key=value pairs + */ +int db_sqlite_insert(const db1_con_t* _h, const db_key_t* _k, const db_val_t* _v, + int _n) +{ + int rc = -1; + + rc = db_do_insert(_h, _k, _v, _n, + db_sqlite_val2str, + db_sqlite_submit_query); + if (rc == 0) + rc = db_sqlite_commit(_h); + db_sqlite_cleanup_query(_h); + + return rc; +} + + +/* + * Delete a row from the specified table + * _h: structure representing database connection + * _k: key names + * _o: operators + * _v: values of the keys that must match + * _n: number of key=value pairs + */ +int db_sqlite_delete(const db1_con_t* _h, const db_key_t* _k, const db_op_t* _o, + const db_val_t* _v, int _n) +{ + int rc; + + rc = db_do_delete(_h, _k, _o, _v, _n, + db_sqlite_val2str, + db_sqlite_submit_query); + if (rc == 0) + rc = db_sqlite_commit(_h); + db_sqlite_cleanup_query(_h); + + return rc; +} + + +/* + * Update some rows in the specified table + * _h: structure representing database connection + * _k: key names + * _o: operators + * _v: values of the keys that must match + * _uk: updated columns + * _uv: updated values of the columns + * _n: number of key=value pairs + * _un: number of columns to update + */ +int db_sqlite_update(const db1_con_t* _h, const db_key_t* _k, const db_op_t* _o, + const db_val_t* _v, const db_key_t* _uk, const db_val_t* _uv, + int _n, int _un) +{ + int rc; + + rc = db_do_update(_h, _k, _o, _v, _uk, _uv, _n, _un, + db_sqlite_val2str, + db_sqlite_submit_query); + if (rc == 0) + rc = db_sqlite_commit(_h); + db_sqlite_cleanup_query(_h); + + return rc; +} + +int db_sqlite_raw_query(const db1_con_t* _h, const str* _s, db1_res_t** _r) +{ + return db_do_raw_query(_h, _s, _r, + db_sqlite_submit_query, + db_sqlite_store_result); +} diff --git a/modules_k/db_sqlite/dbase.h b/modules_k/db_sqlite/dbase.h new file mode 100644 index 0000000..de006bf --- /dev/null +++ b/modules_k/db_sqlite/dbase.h @@ -0,0 +1,72 @@ +/* + * $Id$ + * + * SQlite module core functions + * + * Copyright (C) 2010 Timo Teräs + * + * This file is part of Kamailio, a free SIP server. + * + * Kamailio is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version + * + * Kamailio is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + + +#ifndef DBASE_H +#define DBASE_H + +#include <sqlite3.h> + +#include "../../lib/srdb1/db_pool.h" +#include "../../lib/srdb1/db_con.h" +#include "../../lib/srdb1/db_res.h" +#include "../../lib/srdb1/db_key.h" +#include "../../lib/srdb1/db_op.h" +#include "../../lib/srdb1/db_val.h" + +#define DB_SQLITE_MAX_BINDS 64 + +struct sqlite_connection { + struct pool_con hdr; + + sqlite3 *conn; + int bindpos; + + sqlite3_stmt *stmt; + const db_val_t *bindarg[DB_SQLITE_MAX_BINDS]; +}; + +#define CON_SQLITE(db_con) ((struct sqlite_connection *) db_con->tail) + +db1_con_t* db_sqlite_init(const str* _sqlurl); +void db_sqlite_close(db1_con_t* _h); + +int db_sqlite_free_result(db1_con_t* _h, db1_res_t* _r); + +int db_sqlite_query(const db1_con_t* _h, const db_key_t* _k, const db_op_t* _op, + const db_val_t* _v, const db_key_t* _c, int _n, int _nc, + const db_key_t _o, db1_res_t** _r); +int db_sqlite_insert(const db1_con_t* _h, const db_key_t* _k, const db_val_t* _v, + int _n); +int db_sqlite_delete(const db1_con_t* _h, const db_key_t* _k, const db_op_t* _o, + const db_val_t* _v, int _n); +int db_sqlite_update(const db1_con_t* _h, const db_key_t* _k, const db_op_t* _o, + const db_val_t* _v, const db_key_t* _uk, const db_val_t* _uv, + int _n, int _un); +int db_sqlite_raw_query(const db1_con_t* _h, const str* _s, db1_res_t** _r); + +int db_sqlite_use_table(db1_con_t* _h, const str* _t); + + +#endif /* DBASE_H */ -- 1.7.1

3 3

SIP NOTIFY problem in "presence_dialoginfo" module?
by Klaus Feichtinger 04 Apr '11

04 Apr '11

Hello list, I have a special situation in which string characters of the "root-line" of the notify-body are overwritten by Kamailio. In detail: the root-line of the NOTIFY message sent to the subscriber looks like: <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="1" ll" entity="sip:117090@10.16.10.99"> instead of <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="1" state="full" entity="sip:117090@10.16.10.99"> In other words: the string state="full" is overwritten by space characters. Therefore the message is no longer "valid" and the parser of the subscriber-user agent has problems.... The exact scenario in my use case is, that user agents can subscribe the events "presence" and "dialog" on Kamailio. The information about presence and dialog-states is published to Kamailio by PUBLISH messages from the user agents themselves. Kamailio does not have to generate this information itself. In the following lines I have an excerpt of the signalisation: 1) initial subscription of party A, 2) the responded notification (without body) 3) subscription of party B 4) the responded notification (with body) 5) a publish message of the subscribed party B with actual dialog information and 6) the notification with body to the subscriber A. 1) Initial SUBSCRIBE message of party A: ======================================SUBSCRIBE sip:117090@10.16.10.99 SIP/2.0 Via: SIP/2.0/UDP 10.16.10.93:5060;rport;branch=z9hG4bK1411449981 From: <sip:117093@10.16.10.99>;tag=2453899634-24035392-1301468026894 To: <sip:117090@10.16.10.99> Call-ID: 2442490492-24035392-1301468026894(a)10.16.10.93 CSeq: 20 SUBSCRIBE Contact: <sip:117093@10.16.10.93:5060> Max-Forwards: 70 User-Agent: SipTapi Expires: 3600 Event: dialog Content-Length: 0 2) Responded NOTIFY message from Kamailio: ========================================NOTIFY sip:117093@10.16.10.93:5060 SIP/2.0 Via: SIP/2.0/UDP 10.16.10.99;branch=z9hG4bK7cc7.08e060b6000000000000000000000000.0 To: sip:117093@10.16.10.99;tag=2453899634-24035392-1301468026894 From: sip:117090@10.16.10.99;tag=a23c71953194c2c72e41c4d20e4f7127-86e1 CSeq: 1 NOTIFY Call-ID: 2442490492-24035392-1301468026894(a)10.16.10.93 Content-Length: 0 User-Agent: kamailio (3.1.2 (i386/linux)) Max-Forwards: 70 Event: dialog Contact: <sip:10.16.10.99:5060> Subscription-State: active;expires=3670 3) Initial SUBSCRIBE message of party B: ======================================SUBSCRIBE sip:117093@10.16.10.99 SIP/2.0 Via: SIP/2.0/UDP 10.16.10.90:5060;rport;branch=z9hG4bK4016956575 From: <sip:117090@10.16.10.99>;tag=2605346227-26329880-1301468174702 To: <sip:117093@10.16.10.99> Call-ID: 2982039389-26329880-1301468174702(a)10.16.10.90 CSeq: 20 SUBSCRIBE Contact: <sip:117090@10.16.10.90:5060> Max-Forwards: 70 User-Agent: SipTapi Expires: 3600 Event: dialog Content-Length: 0 4) Responded NOTIFY message from Kamailio (with version number "00000000000"!!!!): ==============================================================================NOTIFY sip:117090@10.16.10.90:5060 SIP/2.0 Via: SIP/2.0/UDP 10.16.10.99;branch=z9hG4bK10e8.31cb2284000000000000000000000000.0 To: sip:117090@10.16.10.99;tag=2605346227-26329880-1301468174702 From: sip:117093@10.16.10.99;tag=a23c71953194c2c72e41c4d20e4f7127-5f56 CSeq: 1 NOTIFY Call-ID: 2982039389-26329880-1301468174702(a)10.16.10.90 Content-Length: 593 User-Agent: kamailio (3.1.2 (i386/linux)) Max-Forwards: 70 Event: dialog Contact: <sip:10.16.10.99:5060> Subscription-State: active;expires=3670 Content-Type: application/dialog-info+xml <?xml version="1.0"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="00000000000" state="full" entity="117093(a)10.16.10.99"> <dialog id="3375446242-26591296-1301467877329(a)10.16.10.93" call-id="3375446242-26591296-1301467877329(a)10.16.10.93" direction="initiator"> <state>terminated</state> <remote> <identity>sip:019992116002@10.16.10.99</identity> <target uri="sip:019992116002@10.16.10.99"/> </remote> <local> <identity>sip:117093@10.16.10.99</identity> <target uri="sip:117093@10.16.10.99"/> </local> </dialog> </dialog-info> 5) The subscribed party is sending a PUBLISH message with following information: ============================================================================PUBLISH sip:117090@10.16.10.99 SIP/2.0 Via: SIP/2.0/UDP 10.16.10.90:5060;rport;branch=z9hG4bK348084694 From: <sip:117090@10.16.10.99>;tag=3644648667-26329880-1301468223499 To: <sip:117090@10.16.10.99> Call-ID: 332031778-26329880-1301468223499(a)10.16.10.90 CSeq: 20 PUBLISH Max-Forwards: 70 User-Agent: SipTapi Content-Disposition: render;handling=required Expires: 3600 Event: dialog Content-Type: application/dialog-info+xml Content-Length: 592 <?xml version="1.0"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="4" state="full" entity="sip:117090@10.16.10.99"> <dialog id="2769397361-26329880-1301468223108(a)10.16.10.90" call-id="2769397361-26329880-1301468223108(a)10.16.10.90" direction="initiator"> <state>confirmed</state> <remote> <identity><sip:116001@10.16.10.99></identity> <target uri="<sip:116001@10.16.10.99>"/> </remote> <local> <identity>sip:117090@10.16.10.99</identity> <target uri="sip:117090@10.16.10.99"/> </local> </dialog> </dialog-info> 6) Status informative NOTIFY message from Kamailio (built from the PUBLISH message above - with correct version but string overwriting!!!): =======================================================================================================================================NOTIFY sip:117093@10.16.10.93:5060 SIP/2.0 Via: SIP/2.0/UDP 10.16.10.99;branch=z9hG4bK4cc7.faa8dc87000000000000000000000000.0 To: sip:117093@10.16.10.99;tag=2453899634-24035392-1301468026894 From: sip:117090@10.16.10.99;tag=a23c71953194c2c72e41c4d20e4f7127-86e1 CSeq: 2 NOTIFY Call-ID: 2442490492-24035392-1301468026894(a)10.16.10.93 Content-Length: 592 User-Agent: kamailio (3.1.2 (i386/linux)) Max-Forwards: 70 Event: dialog Contact: <sip:10.16.10.99:5060> Subscription-State: active;expires=3570 Content-Type: application/dialog-info+xml <?xml version="1.0"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="1" ll" entity="sip:117090@10.16.10.99"> <dialog id="2769397361-26329880-1301468223108(a)10.16.10.90" call-id="2769397361-26329880-1301468223108(a)10.16.10.90" direction="initiator"> <state>confirmed</state> <remote> <identity><sip:116001@10.16.10.99></identity> <target uri="<sip:116001@10.16.10.99>"/> </remote> <local> <identity>sip:117090@10.16.10.99</identity> <target uri="sip:117090@10.16.10.99"/> </local> </dialog> </dialog-info> Debug information of Kamailio and information in the source code show that the version number "00000000000" is a placeholder only, which should be replaced with a valid version number. However, it seems that there is a problem in handling these strings. The version number is replaced, but in case that the version id is only one character long, ten space characters are inserted- overwriting other information...... Can anybody comment this problem? Is this a bug of the presence_dialoginfo- or another module? Thanks in advance! Regards, Klaus P.S. additional information from source code an debug output of kamailio: notify_body.c: [...] /* The version must be increased for each new document and is a 32bit int. As the version is different for each watcher, we can not set here the correct value. Thus, we just put here a placeholder which will be replaced by the correct value in the aux_body_processing callback. Thus we have CPU intensive XML aggregation only once and can use quick search&replace in the per-watcher aux_body_processing callback. We use 11 chracters as an signed int (although RFC says unsigned int we use signed int as presence module stores "version" in DB as signed int) has max. 10 characters + 1 character for the sign */ [...] Debug information from Kamailio: Ad 4) SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence_dialoginfo [notify_body.c:67]: [pres_user]=117093 [pres_domain]= 10.16.10.99, [n]=1 SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence_dialoginfo [notify_body.c:107]: [pres_user]=117093 [pres_domain]= 10.16.10.99, [n]=1 SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence_dialoginfo [notify_body.c:199]: node type: Element, name: dialog SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence_dialoginfo [notify_body.c:73]: [n_body]=0x835fe54 SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence_dialoginfo [notify_body.c:76]: [*n_body]=<?xml version="1.0"?>#012<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="00000000000" state="full" entity="117093(a)10.16.10.99">#012 <dialog id="6b1de4df-6c9ce978(a)10.16.10.203" call-id="6b1de4df-6c9ce978(a)10.16.10.203" direction="recipient">#012 <state>confirmed</state>#012 <remote>#012 <identity>sip:116001@10.16.10.99</identity>#012 <target uri="sip:116001@10.16.10.99"/>#012 </remote>#012 <local>#012 <identity>sip:117093@10.16.10.99</identity>#012 <target uri="sip:117093@10.16.10.99"/>#012 </local>#012 </dialog>#012</dialog-info>#012 SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence_dialoginfo [notify_body.c:328]: replace version with "1" SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence [notify.c:1461]: dialog info: SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence [notify.c:122]: #012#011[pres_uri]= sip:117093@10.16.10.99#012#011[to_user]117093#011[to_domain]= 10.16.10.99#012#011[w_user]= 117090#011[w_domain]10.16.10.99#012#011[event]= dialog#012#011[status]= active#012#011[expires]3519#012#011[callid]3119346140-8635704-1301477522967(a)10.16.10.90#011[local_cseq]=1#012#011[to_tag ]= a23c71953194c2c72e41c4d20e4f7127-7529#011[from_tag]2282475328-8635704-1301477522967#012#011[contact]sip:117090@10.16.10.90:5060#011[record_route]SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence [notify.c:234]: expires 3519 SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence [notify.c:1555]: headers:#012Max-Forwards: 70#015#012Event: dialog#015#012Contact: <sip:10.16.10.99:5060>#015#012Subscription-State: active;expires=3570#015#012Content-Type: application/dialog-info+xml#015#012 SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence [notify.c:940]: CONTACT sip:117090@10.16.10.90:5060 SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: <core> [socket_info.c:501]: grep_sock_info - checking if host==us: 11==11 && [10.16.10.99] =[10.16.10.99] SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: <core> [socket_info.c:504]: grep_sock_info - checking if port 5060 matches port 5060 SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence [notify.c:1729]: ==22/6/37 SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: tm [uac.c:240]: DEBUG:tm:t_uac: next_hop=<sip:117090@10.16.10.90:5060> SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: tm [uac.c:181]: DEBUG: dlg2hash: 27355 SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil) SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil) SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil) SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil) SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil) SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil) SipSrv1 /usr/sbin/kamailio[26764]: INFO: presence [notify.c:1586]: NOTIFY sip:117090@10.16.10.99 via sip:117090@10.16.10.90:5060 on behalf of sip:117093@10.16.10.99 for event dialog Ad 6) SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence_dialoginfo [notify_body.c:67]: [pres_user]=117093 [pres_domain]= 10.16.10.99, [n]=1 SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence_dialoginfo [notify_body.c:107]: [pres_user]=117093 [pres_domain]= 10.16.10.99, [n]=1 SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence_dialoginfo [notify_body.c:199]: node type: Element, name: dialog SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence_dialoginfo [notify_body.c:73]: [n_body]=0x835fcb0 SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence_dialoginfo [notify_body.c:76]: [*n_body]=<?xml version="1.0"?>#012<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="00000000000" state="full" entity="117093(a)10.16.10.99">#012 <dialog id="6b1de4df-6c9ce978(a)10.16.10.203" call-id="6b1de4df-6c9ce978(a)10.16.10.203" direction="recipient">#012 <state>terminated</state>#012 <remote>#012 <identity>sip:116001@10.16.10.99</identity>#012 <target uri="sip:116001@10.16.10.99"/>#012 </remote>#012 <local>#012 <identity>sip:117093@10.16.10.99</identity>#012 <target uri="sip:117093@10.16.10.99"/>#012 </local>#012 </dialog>#012</dialog-info>#012 SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence_dialoginfo [notify_body.c:328]: replace version with "2" SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence [notify.c:1461]: dialog info: SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence [notify.c:122]: #012#011[pres_uri]= sip:117093@10.16.10.99#012#011[to_user]117093#011[to_domain]= 10.16.10.99#012#011[w_user]= 117090#011[w_domain]10.16.10.99#012#011[event]= dialog#012#011[status]= active#012#011[expires]3242#012#011[callid]3119346140-8635704-1301477522967(a)10.16.10.90#011[local_cseq]=2#012#011[to_tag ]= a23c71953194c2c72e41c4d20e4f7127-7529#011[from_tag]2282475328-8635704-1301477522967#012#011[contact]sip:117090@10.16.10.90:5060#011[record_route]= SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence [notify.c:234]: expires 3242 SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence [notify.c:1555]: headers:#012Max-Forwards: 70#015#012Event: dialog#015#012Contact: <sip:10.16.10.99:5060>#015#012Subscription-State: active;expires=3270#015#012Content-Type: application/dialog-info+xml#015#012 SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence [notify.c:940]: CONTACT sip:117090@10.16.10.90:5060 SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: <core> [socket_info.c:501]: grep_sock_info - checking if host==us: 11==11 && [10.16.10.99] =[10.16.10.99] SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: <core> [socket_info.c:504]: grep_sock_info - checking if port 5060 matches port 5060 SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence [notify.c:1729]: ==22/6/37 SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: tm [uac.c:240]: DEBUG:tm:t_uac: next_hop=<sip:117090@10.16.10.90:5060> SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: tm [uac.c:181]: DEBUG: dlg2hash: 27356 SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil) SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil) SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil) SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil) SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil) SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil) SipSrv1 /usr/sbin/kamailio[26764]: INFO: presence [notify.c:1586]: NOTIFY sip:117090@10.16.10.99 via sip:117090@10.16.10.90:5060 on behalf of sip:117093@10.16.10.99 for event dialog

3 6

Suggestion dialog module / $dlg_ctx() problem.
by Alexandre Abreu 04 Apr '11

04 Apr '11

Hello. Using K 3.1.2. Before the setflag() that creates the dialog, I tried to use: $dlg_ctx(flags) = 1; Mar 30 12:29:03 devel kamailio: ERROR: dialog [dlg_var.c:165]: unknown PV name flags Mar 30 12:29:03 devel kamailio: ERROR: <core> [pvapi.c:565]: pvar "dlg_ctx" has an invalid name param [flags] Mar 30 12:29:03 devel kamailio: ERROR: <core> [pvapi.c:720]: wrong char [)/41] in [$dlg_ctx(flags)] at [14 (5)] Mar 30 12:29:03 devel kamailio: : <core> [cfg.y:3409]: parse error in config file /usr/local/etc/kamailio/kamailio.cfg, line 308, column 9-23: unknown script pseudo variable $dlg_ctx(flags) Right now, my goal is to add the user-agent content header ($ua) from caller/callee and list them through 'dlg_list_ctx'. I would suggest something like that: Request route: $dlg_ctx(set->ua_src) = $ua; On reply route: $dlg_ctx(set->ua_dst) = $ua; dlg_list_ctx: . ua_src:: X-Lite 3.0 build 666 ua_dst:: Linksys PAP2 . Does this suggestion make sense? Using another approach is it possible to execute this today? Thanks, Alexandre

4 11

preparing kamailio v3.1.3
by Daniel-Constantin Mierla 04 Apr '11

04 Apr '11

Hello, it is almost 2 months since we packaged 3.1.2, there are commits accumulated in branch 3.1, therefore I plan to package 3.1.3 Monday or Tuesday next week. If anyone has something to add in this regards, please reply. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

1 1

library dir for x86_64 - lib or lib64
by Daniel-Constantin Mierla 04 Apr '11

04 Apr '11

Hello, iirc this was at some point discussed, however, I want to go through it again. Many x86_64 distros expect libraries to be placed under a lib64 directory. For example the RPM spec file language returns /usr/lib64 for %{_libdir} variable. In the master branch I committed a patch that does this detection. As I saw some people saying that 'lib' should be the default also for x86_64, my question is then what do you think we should use? Using 'lib' will definitely make building rpms fail unless we do a patch specific for these distros. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

3 2

meeting in thailand bangkoke
by Meftah Tayeb 03 Apr '11

03 Apr '11

hi guys i'm in thailand right now this week i'm staying in bangkoke anyone want to meet please drop me an email thank you -- Meftah Tayeb inum: +883510001288000 phone: +13477595883

1 0

Setting Global Variables
by Nathaniel L Keeling 02 Apr '11

02 Apr '11

Hello, I am trying to use global variables within my configuration script. I am using Kamailio v3.0.0 and I am following the syntax example written in the sample config file but I keep getting syntax errors. Here is a copy of my syntax and I am using cfg_get.voicemailserver.bindip to get the value. #!ifdef WITH_VOICEMAIL voicemailserver.bindip = "10.0.0.1" desc "Voicemail Server IP Address" voicemailserver.bindport = "5060" desc "Voicemail Server Port" #!endif Here is the error that I am receiving: 0(1875) : <core> [cfg.y:3333]: parse error in config file /usr/local/kamailio-3.0.0/etc/kamailio/kamailio.cfg, line 156, column 17: syntax error 0(1875) : <core> [cfg.y:3333]: parse error in config file /usr/local/kamailio-3.0.0/etc/kamailio/kamailio.cfg, line 156, column 17: unknown config variable 0(1875) : <core> [cfg.y:3330]: parse error in config file /usr/local/kamailio-3.0.0/etc/kamailio/kamailio.cfg, line 156, column 19-28: ERROR: bad config file (3 errors) 0(1875) DEBUG: <core> [mem/shm_mem.c:236]: shm_mem_destroy Thanks Nathaniel

1 0

Avpops problem - bad avp flags.
by Ricardo Martinez 01 Apr '11

01 Apr '11

Hello. I’m having a problems using the avpops with the kamailio version 3.1.2 I have the next configuration: modparam("avpops", "db_url", "mysql://openser:openserrw@localhost/openser") modparam("avpops", "avp_table", "usr_preferences") ----- route[REQINIT] { if( !(avp_db_load("pike", "s:ip_origen") && avp_check("s:ip_origen", "eq/$src_ip/gi")) ) { … } mysql> select * from usr_preferences; +----+------+----------+--------+-----------+------+---------------+---------------------+ | id | uuid | username | domain | attribute | type | value | last_modified | +----+------+----------+--------+-----------+------+---------------+---------------------+ | 1 | pike | 0 | | ip_origen | 0 | 100.20.100.20 | 1900-01-01 00:00:01 | +----+------+----------+--------+-----------+------+---------------+---------------------+ 1 row in set (0.00 sec) When I try to start kamailio I’m getting the next error : Apr 1 10:36:08 kamailio[15418]: ERROR: avpops [avpops_parse.c:129]: error - bad avp flags Apr 1 10:36:08 kamailio[15418]: ERROR: avpops [avpops.c:299]: parse failed Apr 1 10:36:08 kamailio[15418]: ERROR: <core> [route.c:1161]: fixing failed (code=-1) at cfg:/usr/local/etc/kamailio/kamailio.cfg:238 Apr 1 10:36:08 kamailio[15418]: ERROR: <core> [route.c:1161]: fixing failed (code=-1) at cfg:/usr/local/etc/kamailio/kamailio.cfg:263 I can’t find the problem. Can someone help me? Regards. Ricardo.-

2 1

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

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