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
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.-
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
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
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
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
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
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.-
* *
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>
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
