sr-users December 2010

sr-users@lists.kamailio.org

63 participants
114 discussions

Kamailio 3.1.x and Asterisk 1.6.2 Realtime Integration using Asterisk Database
by Kurt Mullen 29 Dec '10

29 Dec '10

I am on my 20th (I'm not kidding) attempt to successfully complete this tutorial. I have installed on Ubuntu 10.10 x64 Server. I installed Kamailio & Asterisk on the same server as in the tutorial. I have two SIP clients registered, but they are not able to call each other. No one answered my last two posts, so I hope someone can help this time. Kurt Mullen

3 2

LCR and gateways resource.
by Ricardo Martinez 29 Dec '10

29 Dec '10

Hello. I’m looking for a way to mix the features of LCR and a counter to keep track of the used resource of a gateway. Let me explain. Let’s suppose that I’m using LCR module to route the calls to all my gateways, in particular I have the calls with prefix 55 routed to the group “55” which are 3 gateways : GW1, GW2 and GW3. Let’s suppose also that each gateway is connected to digital E1 with 30 channels. At certain time of the day one of the gateways is at full capacity using the 30 channels. This is what I wanted to do : can I have a variable with the maximum channels available for a certain gateway, and for each call going to that gateway a counter?. When the counter reach the maximum, can I remove the gateway from the LCR choosing algorithm until it has capacity again? Can I have some thoughts about this idea? Is there a way to achieve this ? Thanks in advance. Regards, Ricardo.-

2 3

Swap of From and To - kamailio 3.1.x problem?
by Jeremya 28 Dec '10

28 Dec '10

Hi I have a problem which pops up occasionally. My scenario is a kamailio 3.0.x server coupled with SEMS 1.2.1 Calls go to SEMS and occasionally it will issue a refer to the caller (an SPA962 linksys) The problem is that the refer seems to get screwed up somewhere and the referred call changes the From field to the To field - in this case 711. The problems start below at 15:58:21 after the refer I'd like to know if this is a problem with Kamailio or a problem with the phone. The call fails on the SEMS_SEND section when the From field is validated. I suspect the phone is the culprit, but external advice appreciated. I'm not quite sure what the s_xxx call id means? Here is the log Dec 24 15:58:20 mc0 /usr/local/sbin/kamailio[399]: WARNING: <script>: f43507d4-e02f109b(a)10.1.39.192 (New request) Method:<REFER> r-uri <sip:711@10.50.20.10:5070;LINEID=fac9f6b7cb08> To: sip:711@joondalup.fesa.sto From: sip:902@fesa.sto Dec 24 15:58:20 mc0 /usr/local/sbin/kamailio[399]: WARNING: <script>: f43507d4-e02f109b(a)10.1.39.192 ( reply etc ) Method:<REFER> r-uri <sip:711@10.50.20.10:5070;LINEID=fac9f6b7cb08> To: sip:711@joondalup.fesa.sto From: sip:902@fesa.sto Dec 24 15:58:20 mc0 /usr/local/sbin/kamailio[399]: WARNING: <script>: f43507d4-e02f109b(a)10.1.39.192 (Loose route) Method:<REFER> r-uri <sip:711@10.50.20.10:5070;LINEID=fac9f6b7cb08> To: sip:711@joondalup.fesa.sto From: sip:902@fesa.sto Dec 24 15:58:20 mc0 /usr/local/sbin/kamailio[399]: WARNING: <script>: f43507d4-e02f109b(a)10.1.39.192 (RELAY, start of processing) Method:<REFER> r-uri <sip:711@10.50.20.10:5070;LINEID=fac9f6b7cb08> To: sip:711@joondalup.fesa.sto From: sip:902@fesa.sto Dec 24 15:58:21 mc0 /usr/local/sbin/kamailio[399]: WARNING: <script>: s_275259592d_358d20ea49bf (New request) Method:<INVITE> r-uri <sip:7020@fesa.sto> To: sip:7020@fesa.sto From: sip:711@10.50.20.10:5070;LINEID=fac9f6b7cb08 Dec 24 15:58:21 mc0 /usr/local/sbin/kamailio[399]: WARNING: <script>: s_275259592d_358d20ea49bf (handle initial request) Method:<INVITE> r-uri <sip:7020@fesa.sto> To: sip:7020@fesa.sto From: sip:711@10.50.20.10:5070;LINEID=fac9f6b7cb08 Dec 24 15:58:21 mc0 /usr/local/sbin/kamailio[399]: WARNING: <script>: s_275259592d_358d20ea49bf (t_check_trans) Method:<INVITE> r-uri <sip:7020@fesa.sto> To: sip:7020@fesa.sto From: sip:711@10.50.20.10:5070;LINEID=fac9f6b7cb08 Dec 24 15:58:21 mc0 /usr/local/sbin/kamailio[399]: WARNING: <script>: s_275259592d_358d20ea49bf (Request For Me) Method:<INVITE> r-uri <sip:7020@fesa.sto> To: sip:7020@fesa.sto From: sip:711@10.50.20.10:5070;LINEID=fac9f6b7cb08 Dec 24 15:58:21 mc0 /usr/local/sbin/kamailio[399]: WARNING: <script>: s_275259592d_358d20ea49bf (SEMS, rewrites) Method:<INVITE> r-uri <sip:020@fesa.sto> To: sip:7020@fesa.sto From: sip:711@10.50.20.10:5070;LINEID=fac9f6b7cb08 Dec 24 15:58:21 mc0 /usr/local/sbin/kamailio[399]: WARNING: <script>: s_275259592d_358d20ea49bf (SEMS_SEND) Method:<INVITE> r-uri <sip:020@fesa.sto> To: sip:7020@fesa.sto From: sip:711@10.50.20.10:5070;LINEID=fac9f6b7cb08 Dec 24 15:58:21 mc0 /usr/local/sbin/kamailio[398]: WARNING: <script>: s_275259592d_358d20ea49bf (SEMS_SEND_REPLY) Method:<INVITE> Status:<603> Dec 24 15:58:21 mc0 /usr/local/sbin/kamailio[398]: CRITICAL: <script>: s_275259592d_358d20ea49bf (SEMS_SEND_FAIL) Method:<INVITE> Status:<<null>> Dec 24 15:58:21 mc0 /usr/local/sbin/kamailio[404]: WARNING: <script>: s_275259592d_358d20ea49bf (New request) Method:<ACK> r-uri <sip:7020@fesa.sto> To: sip:7020@fesa.sto From: sip:711@10.50.20.10:5070;LINEID=fac9f6b7cb08 Dec 24 15:58:21 mc0 /usr/local/sbin/kamailio[404]: WARNING: <script>: s_275259592d_358d20ea49bf ( reply etc ) Method:<ACK> r-uri <sip:7020@fesa.sto> To: sip:7020@fesa.sto From: sip:711@10.50.20.10:5070;LINEID=fac9f6b7cb08 Dec 24 15:58:21 mc0 /usr/local/sbin/kamailio[404]: WARNING: <script>: s_275259592d_358d20ea49bf (Not a loose route) Method:<ACK> r-uri <sip:7020@fesa.sto> To: sip:7020@fesa.sto From: sip:711@10.50.20.10:5070;LINEID=fac9f6b7cb08 Dec 24 15:58:21 mc0 /usr/local/sbin/kamailio[404]: WARNING: <script>: s_275259592d_358d20ea49bf (ACK in lr) Method:<ACK> r-uri <sip:7020@fesa.sto> To: sip:7020@fesa.sto From: sip:711@10.50.20.10:5070;LINEID=fac9f6b7cb08

2 1

Crash
by michel freiha 28 Dec '10

28 Dec '10

Hi all, I have latest version of kamailio but it keep crashing...I know that the log could not be sufficient but maybe anyone faced the same issue before...Please find log below and let me know if you can find anything Nov 24 15:56:23 tunnel /usr/local/sbin/kamailio[19943]: : <core> [pass_fd.c:293]: ERROR: receive_fd: EOF on 15 Nov 24 15:56:23 tunnel /usr/local/sbin/kamailio[19929]: ALERT: <core> [main.c:741]: child process 19935 exited by a signal 11 Nov 24 15:56:23 tunnel /usr/local/sbin/kamailio[19932]: INFO: carrierroute [cr_func.c:595]: uri 919437452006 was rewritten to sip:919437452006@x.x.x.x, carrier 5, domain 0 Nov 24 15:56:24 tunnel /usr/local/sbin/kamailio[19930]: INFO: carrierroute [cr_func.c:595]: uri 008801823703200 was rewritten to sip:008801823703200@X.X.X.5, carrier 5, domain 0 Nov 24 15:56:24 tunnel /usr/local/sbin/kamailio[19933]: ERROR: <script>: CARRIERROUTE_time_dbg:method=INVITE;time=1290614183;callid=14b6536a-d102-1910-9b23-9f3b3c3065ca - before cr Nov 24 15:56:24 tunnel /usr/local/sbin/kamailio[19929]: ALERT: <core> [main.c:744]: core was generated Nov 24 15:56:24 tunnel /usr/local/sbin/kamailio[19932]: INFO: <script>: time_dbg:method=SUBSCRIBE;time=1290614183;callid=YjVmODYzYjQxYWY0ZTU3MGRmMmZkYjRhOTg4ZGZmODQ. - before cr Nov 24 15:56:24 tunnel /usr/local/sbin/kamailio[19930]: INFO: <script>: time_dbg:method=INVITE;time=1290614183;callid=cdc9556a-d102-1910-8b30-926b495dad44 - before cr Nov 24 15:56:24 tunnel /usr/local/sbin/kamailio[19933]: INFO: carrierroute [cr_func.c:595]: uri 00919974265815 was rewritten to sip:00919974265815@X.X.X.X>, carrier 5, domain 0 Nov 24 15:56:24 tunnel /usr/local/sbin/kamailio[19931]: ERROR: <script>: time_dbg:method=INVITE;time=1290614182;callid=14b6536a-d102-1910-9b23-9f3b3c3065ca - before t_relay Nov 24 15:56:24 tunnel /usr/local/sbin/kamailio[19929]: INFO: <core> [main.c:756]: INFO: terminating due to SIGCHLD Nov 24 15:56:24 tunnel /usr/local/sbin/kamailio[19934]: INFO: <core> [main.c:807]: INFO: signal 15 received Nov 24 15:56:24 tunnel /usr/local/sbin/kamailio[19943]: INFO: <core> [main.c:807]: INFO: signal 15 received Nov 24 15:56:24 tunnel /usr/local/sbin/kamailio[19942]: INFO: <core> [main.c:807]: INFO: signal 15 received Nov 24 15:56:24 tunnel /usr/local/sbin/kamailio[19940]: INFO: <core> [main.c:807]: INFO: signal 15 received Nov 24 15:56:24 tunnel /usr/local/sbin/kamailio[19939]: INFO: <core> [main.c:807]: INFO: signal 15 received Nov 24 15:56:24 tunnel /usr/local/sbin/kamailio[19938]: INFO: <core> [main.c:807]: INFO: signal 15 received Nov 24 15:56:24 tunnel /usr/local/sbin/kamailio[19941]: INFO: <core> [main.c:807]: INFO: signal 15 received Nov 24 15:56:24 tunnel /usr/local/sbin/kamailio[19937]: INFO: <core> [main.c:807]: INFO: signal 15 received Nov 24 15:56:24 tunnel /usr/local/sbin/kamailio[19936]: INFO: <core> [main.c:807]: INFO: signal 15 received Regards

4 21

Merry Christmas!
by Daniel-Constantin Mierla 27 Dec '10

27 Dec '10

Hello, I could safety say that 2010 was the greatest year by achievements in the history of our SIP proxy server project so far. It will not be short to summarize it, so I will do a separate post for that. Now I just wast to thank everyone making that possible and wish you a Merry Christmas! Great winter holidays to all Kamailians and SERians!!! Cheers, Daniel -- Daniel-Constantin Mierla Kamailio (OpenSER) Advanced Training Jan 24-26, 2011, Irvine, CA, USA http://www.asipto.com

3 3

Puzzling swap of To and From - Kamailio 3.0x
by Jeremy Ardley 24 Dec '10

24 Dec '10

Hi I have a problem which pops up occasionally. My scenario is a kamailio 3.0.x server coupled with SEMS 1.2.1 Calls go to SEMS and occasionally it will issue a refer to the caller (an SPA962 linksys) The problem is that the refer seems to get screwed up somewhere and the new call changes the From field to the To field - in this case 711. The problems start below at 15:58:21 after the refer I'd like to know if this is a problem with Kamailio or a problem with the phone. The call fails on the SEMS_SEND section when the From field is validated. I suspect the phone is the culprit, but external advice appreciated. Here is the log Dec 24 15:58:20 mc0 /usr/local/sbin/kamailio[399]: WARNING: <script>: f43507d4-e02f109b(a)10.1.39.192 (New request) Method:<REFER> r-uri <sip:711@10.50.20.10:5070;LINEID=fac9f6b7cb08> To: sip:711@joondalup.fesa.sto From: sip:902@fesa.sto Dec 24 15:58:20 mc0 /usr/local/sbin/kamailio[399]: WARNING: <script>: f43507d4-e02f109b(a)10.1.39.192 ( reply etc ) Method:<REFER> r-uri <sip:711@10.50.20.10:5070;LINEID=fac9f6b7cb08> To: sip:711@joondalup.fesa.sto From: sip:902@fesa.sto Dec 24 15:58:20 mc0 /usr/local/sbin/kamailio[399]: WARNING: <script>: f43507d4-e02f109b(a)10.1.39.192 (Loose route) Method:<REFER> r-uri <sip:711@10.50.20.10:5070;LINEID=fac9f6b7cb08> To: sip:711@joondalup.fesa.sto From: sip:902@fesa.sto Dec 24 15:58:20 mc0 /usr/local/sbin/kamailio[399]: WARNING: <script>: f43507d4-e02f109b(a)10.1.39.192 (RELAY, start of processing) Method:<REFER> r-uri <sip:711@10.50.20.10:5070;LINEID=fac9f6b7cb08> To: sip:711@joondalup.fesa.sto From: sip:902@fesa.sto Dec 24 15:58:21 mc0 /usr/local/sbin/kamailio[399]: WARNING: <script>: s_275259592d_358d20ea49bf (New request) Method:<INVITE> r-uri <sip:7020@fesa.sto> To: sip:7020@fesa.sto From: sip:711@10.50.20.10:5070;LINEID=fac9f6b7cb08 Dec 24 15:58:21 mc0 /usr/local/sbin/kamailio[399]: WARNING: <script>: s_275259592d_358d20ea49bf (handle initial request) Method:<INVITE> r-uri <sip:7020@fesa.sto> To: sip:7020@fesa.sto From: sip:711@10.50.20.10:5070;LINEID=fac9f6b7cb08 Dec 24 15:58:21 mc0 /usr/local/sbin/kamailio[399]: WARNING: <script>: s_275259592d_358d20ea49bf (t_check_trans) Method:<INVITE> r-uri <sip:7020@fesa.sto> To: sip:7020@fesa.sto From: sip:711@10.50.20.10:5070;LINEID=fac9f6b7cb08 Dec 24 15:58:21 mc0 /usr/local/sbin/kamailio[399]: WARNING: <script>: s_275259592d_358d20ea49bf (Request For Me) Method:<INVITE> r-uri <sip:7020@fesa.sto> To: sip:7020@fesa.sto From: sip:711@10.50.20.10:5070;LINEID=fac9f6b7cb08 Dec 24 15:58:21 mc0 /usr/local/sbin/kamailio[399]: WARNING: <script>: s_275259592d_358d20ea49bf (SEMS, rewrites) Method:<INVITE> r-uri <sip:020@fesa.sto> To: sip:7020@fesa.sto From: sip:711@10.50.20.10:5070;LINEID=fac9f6b7cb08 Dec 24 15:58:21 mc0 /usr/local/sbin/kamailio[399]: WARNING: <script>: s_275259592d_358d20ea49bf (SEMS_SEND) Method:<INVITE> r-uri <sip:020@fesa.sto> To: sip:7020@fesa.sto From: sip:711@10.50.20.10:5070;LINEID=fac9f6b7cb08 Dec 24 15:58:21 mc0 /usr/local/sbin/kamailio[398]: WARNING: <script>: s_275259592d_358d20ea49bf (SEMS_SEND_REPLY) Method:<INVITE> Status:<603> Dec 24 15:58:21 mc0 /usr/local/sbin/kamailio[398]: CRITICAL: <script>: s_275259592d_358d20ea49bf (SEMS_SEND_FAIL) Method:<INVITE> Status:<<null>> Dec 24 15:58:21 mc0 /usr/local/sbin/kamailio[404]: WARNING: <script>: s_275259592d_358d20ea49bf (New request) Method:<ACK> r-uri <sip:7020@fesa.sto> To: sip:7020@fesa.sto From: sip:711@10.50.20.10:5070;LINEID=fac9f6b7cb08 Dec 24 15:58:21 mc0 /usr/local/sbin/kamailio[404]: WARNING: <script>: s_275259592d_358d20ea49bf ( reply etc ) Method:<ACK> r-uri <sip:7020@fesa.sto> To: sip:7020@fesa.sto From: sip:711@10.50.20.10:5070;LINEID=fac9f6b7cb08 Dec 24 15:58:21 mc0 /usr/local/sbin/kamailio[404]: WARNING: <script>: s_275259592d_358d20ea49bf (Not a loose route) Method:<ACK> r-uri <sip:7020@fesa.sto> To: sip:7020@fesa.sto From: sip:711@10.50.20.10:5070;LINEID=fac9f6b7cb08 Dec 24 15:58:21 mc0 /usr/local/sbin/kamailio[404]: WARNING: <script>: s_275259592d_358d20ea49bf (ACK in lr) Method:<ACK> r-uri <sip:7020@fesa.sto> To: sip:7020@fesa.sto From: sip:711@10.50.20.10:5070;LINEID=fac9f6b7cb08

1 0

Billing
by Deon Vermeulen 24 Dec '10

24 Dec '10

Good Day list Is there someone that could guide me to installation guide for jBilling or recommend any other Free OpenSource Billing? Features Looking for: - Wholesale - Rating - Pre-Paid/Post-Paid Thank you very much Regards Deon

2 1

Source IP address in Failure_route
by Ricardo Martinez 24 Dec '10

24 Dec '10

Hello. I’m trying to obtain the source IP address from a reply message. This is part of the configuration file : failure_route[1] { if (t_was_cancelled()) { xlog("L_INFO", "[$ci] $rm:$ru t_was_cancelled in failure_route\n"); exit; } if ( ($T_rpl($si) != "10.0.0.4") || ($T_rpl($si) != "10.0.0.3") ) { if ( t_check_status("48[0-9]") ) { xlog("L_INFO","[$ci] 48X Received\n"); exit; } } … But it seems not to be working. Is there a way to do what I want? Thanks in advance, Regards, Ricardo.- * *

4 5

[dialog] No dialog stored if Via has no branch
by Iñaki Baz Castillo 23 Dec '10

23 Dec '10

Hi, using Kamailio 1.5.4. I receive llamadas from a Cisco pre-RFC 3261 (non symmetric SIP and no ;branch parameter). It seems that dialog module cannot account such calls. Maybe branch parameter is required? -- Iñaki Baz Castillo <ibc(a)aliax.net>

2 4

kamailio restart and TLS ( relay_to_tls() )
by Juha Heinanen 22 Dec '10

22 Dec '10

Of course this won't work if you route to the other proxies also using lookup() with permanent entries in location table. If you really have such a setup you can try to set a certain flag for this entries and then do not call set_forward_no_connect(). klaus, i checked and i'm already calling set_forward_no_connect() when initial request is forwarded to a tcp contact. however, it seems more tricky to prevent useless tcp connection attempts for in-dialog requests. for example, here the UA has gone away when presence server sends a notify to it: Dec 22 14:50:48 sip /usr/sbin/sip-proxy[3207]: INFO: Routing in-dialog NOTIFY <sip:gmuodqxs@192.98.102.10:50279;transport=tcp> from <sip:jh@vm.test.fi> to <sip:192.98.102.10:60550;transport=tcp> Dec 22 14:50:48 sip /usr/sbin/sip-proxy[3207]: ERROR: <core> [tcp_main.c:2743]: connect 192.98.102.10:60550 failed (RST) Connection refused Dec 22 14:50:48 sip /usr/sbin/sip-proxy[3207]: ERROR: <core> [tcp_main.c:2753]: 192.98.102.10:60550: connect & send for 0xb2d1c490 failed: Connection refused (111) Dec 22 14:50:48 sip /usr/sbin/sip-proxy[3207]: ERROR: tm [../../forward.h:169]: msg_send: ERROR: tcp_send failed Dec 22 14:50:48 sip /usr/sbin/sip-proxy[3207]: ERROR: tm [t_fwd.c:1382]: ERROR: t_send_branch: sending request on branch 0 failed Dec 22 14:50:48 sip /usr/sbin/sip-proxy[3207]: INFO: Failed to relay in-dialog request NOTIFY <sip:gmuodqxs@192.98.102.10:50279;transport=tcp> it does not seem like a good idea to call set_forward_no_connect() for all in-dialog requests. for example, presence server might have been restarted when in-dialog subscribe arrives to it and it would make sense to for sr to try to setup a tcp session with presence server. same for pstn gateways and other proxies. -- juha

2 1

← Newer
1
2
3
4
5
6
7
...
12
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users December 2010