9 Apr
2009
9 Apr
'09
12:55 p.m.
Hello to all
I have Asterisk forwarding calls through Kamailio.
If calls are placed by an Asterisk extension (like X-Lite) everything
works fine.
( ex: X-Lite -> Asterisk -> Kamailio )
If calls are placed through a Cisco Router (connected to Asterisk)
Kamailio answers:
"513 Message too big"
( ex: Cisco VoIP client -> Cisco Router -> Asterisk -> Kamailio )
Also, the destination phone rings, but the calling party is disconnected
because of this 513 message.
This message if probably being originated here:
if (msg:len >= 2048 ) {
sl_send_reply("513", "Message too big");
exit;
};
What could be the problem?
Is the problem in Kamailio configuration or Asterisk configuration?
And why does the call works when placed by an Asterisk extension, but
doesn't work when placed by an Asterisk connected equipment?
Thanks
Regards
Joao Pereira
--
StarTel - A Rede Livre
Joao Gomes Pereira
www.startel.pt
+351 304500650
sip: gomespereira(a)startel.pt
9 Apr
9 Apr
12:59 p.m.
On 04/09/2009 12:55 PM, Joao Gomes Pereira wrote:
Hello to all
I have Asterisk forwarding calls through Kamailio.
If calls are placed by an Asterisk extension (like X-Lite) everything
works fine.
( ex: X-Lite -> Asterisk -> Kamailio )
If calls are placed through a Cisco Router (connected to Asterisk)
Kamailio answers:
"513 Message too big"
( ex: Cisco VoIP client -> Cisco Router -> Asterisk -> Kamailio )
Also, the destination phone rings, but the calling party is disconnected
because of this 513 message.
This message if probably being originated here:
if (msg:len >= 2048 ) {
sl_send_reply("513", "Message too big");
exit;
};
What could be the problem?
Is the problem in Kamailio configuration or Asterisk configuration?
And why does the call works when placed by an Asterisk extension, but
doesn't work when placed by an Asterisk connected equipment?
Probably there are more headers or bigger, just replace the condition
with something more convenient:
if (msg:len >= 8192 ) {
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com/
1:07 p.m.
Daniel-Constantin Mierla wrote:
On 04/09/2009 12:55 PM, Joao Gomes Pereira wrote:
I was afraid that increasing the message length could cause some
problems.... isn't it bad to have a big value like 8192?
Thanks
Joao Pereira
--
StarTel - A Rede Livre
Joao Gomes Pereira
www.startel.pt
+351 304500650
sip: gomespereira(a)startel.pt
Hello to all
I have Asterisk forwarding calls through Kamailio.
If calls are placed by an Asterisk extension (like X-Lite) everything
works fine.
( ex: X-Lite -> Asterisk -> Kamailio )
If calls are placed through a Cisco Router (connected to Asterisk)
Kamailio answers:
"513 Message too big"
( ex: Cisco VoIP client -> Cisco Router -> Asterisk -> Kamailio )
Also, the destination phone rings, but the calling party is
disconnected because of this 513 message.
This message if probably being originated here:
if (msg:len >= 2048 ) {
sl_send_reply("513", "Message too big");
exit;
};
What could be the problem?
Is the problem in Kamailio configuration or Asterisk configuration?
And why does the call works when placed by an Asterisk extension, but
doesn't work when placed by an Asterisk connected equipment?
Probably there are more headers or bigger, just replace the condition
with something more convenient:
if (msg:len >= 8192 ) {
Cheers,
Daniel
1:13 p.m.
On 04/09/2009 01:07 PM, Joao Gomes Pereira wrote:
Daniel-Constantin Mierla wrote:
not at all. Internal buffer size is much more and if that is exceeded
the config is not executed. The condition is just to prevent malicious
users that could send bloat to fill the pipe. So average of a 2k per sip
message was common so far, but now with presence xml body, more and more
headers, that could be low.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com/
On 04/09/2009 12:55 PM, Joao Gomes Pereira
wrote:
I was afraid that increasing the message length could cause some
problems.... isn't it bad to have a big value like 8192?
Hello to all
I have Asterisk forwarding calls through Kamailio.
If calls are placed by an Asterisk extension (like X-Lite) everything
works fine.
( ex: X-Lite -> Asterisk -> Kamailio )
If calls are placed through a Cisco Router (connected to Asterisk)
Kamailio answers:
"513 Message too big"
( ex: Cisco VoIP client -> Cisco Router -> Asterisk -> Kamailio )
Also, the destination phone rings, but the calling party is
disconnected because of this 513 message.
This message if probably being originated here:
if (msg:len >= 2048 ) {
sl_send_reply("513", "Message too big");
exit;
};
What could be the problem?
Is the problem in Kamailio configuration or Asterisk configuration?
And why does the call works when placed by an Asterisk extension, but
doesn't work when placed by an Asterisk connected equipment?
Probably there are more headers or bigger, just replace the condition
with something more convenient:
if (msg:len >= 8192 ) {
Cheers,
Daniel
1:31 p.m.
2009/4/9 Joao Gomes Pereira <gomespereira(a)startel.pt>pt>:
If calls are placed through a Cisco Router (connected
to Asterisk)
Kamailio answers:
"513 Message too big"
( ex: Cisco VoIP client -> Cisco Router -> Asterisk -> Kamailio )
Also, the destination phone rings, but the calling party is disconnected
because of this 513 message.
Most probably you are getting into loops. Check with ngrep the SIP
flow and you'll realize that Kamailio is sending requests to *itself*.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
2:46 p.m.
Iñaki Baz Castillo wrote:
2009/4/9 Joao Gomes Pereira
<gomespereira(a)startel.pt>pt>:
But how is this possible if the calls work, when placed with an Asterisk
extension?
( ex: X-Lite -> Asterisk -> Kamailio )
Kamailio should see this Asterisk as a client and route the calls the
same way, when placed by an extension or through another Asterisk trunk.
isn't this true?
Thanks
Joao
--
StarTel - A Rede Livre
Joao Gomes Pereira
www.startel.pt
+351 304500650
sip: gomespereira(a)startel.pt
If calls are placed through a Cisco Router
(connected to Asterisk)
Kamailio answers:
"513 Message too big"
( ex: Cisco VoIP client -> Cisco Router -> Asterisk -> Kamailio )
Also, the destination phone rings, but the calling party is disconnected
because of this 513 message.
Most probably you are getting into loops. Check with ngrep the SIP
flow and you'll realize that Kamailio is sending requests to *itself*.
3:29 p.m.
2009/4/9 Joao Gomes Pereira <gomespereira(a)startel.pt>pt>:
We can spent long hours speaking about "how is it possible". What you
should do, as I already suggested, is capturing a SIP trace with ngrep
and inspect what is happening (most probably a loop).
Most probably
you are getting into loops. Check with ngrep the SIP
flow and you'll realize that Kamailio is sending requests to *itself*.
But how is this possible if the calls work, when placed with an Asterisk
extension?
( ex: X-Lite -> Asterisk -> Kamailio ) Kamailio should see this Asterisk as a client and
route the calls the same
way, when placed by an extension or through another Asterisk trunk.
isn't this true?
Probably, but it doesn't mean that your Kamailio config is the correct
one for that case.
Again: ngrep
Also: http://dev.sipdoc.net/wiki/ngrep-sip
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
4:10 p.m.
Iñaki Baz Castillo schrieb:
2009/4/9 Joao Gomes Pereira
<gomespereira(a)startel.pt>pt>:
We can spent long hours speaking about "how is it possible". What you
should do, as I already suggested, is capturing a SIP trace with ngrep
and inspect what is happening (most probably a loop).
Just a hint: use "ngrep -d lo port 5060" to see if SIP messages are looped
klaus
Most
probably you are getting into loops. Check with ngrep the SIP
flow and you'll realize that Kamailio is sending requests to *itself*.
But how is this possible if the calls work, when placed with an Asterisk
extension?
( ex: X-Lite -> Asterisk -> Kamailio ) Kamailio should see this Asterisk as a client and
route the calls the same
way, when placed by an extension or through another Asterisk trunk.
isn't this true?
Probably, but it doesn't mean that your Kamailio config is the correct
one for that case.
Again: ngrep
Also: http://dev.sipdoc.net/wiki/ngrep-sip
5:45 p.m.
Hello
I did ngrep -d lo port 5060
And there are loops, because the message "513 Message too big " appears
lots of times, and always from my IP to my IP
What parts of the configuration could be creating these loops?
Thanks
regards
Joao Pereira
Klaus Darilion wrote:
Iñaki Baz Castillo schrieb:
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
--
StarTel - A Rede Livre
Joao Gomes Pereira
www.startel.pt
+351 304500650
sip: gomespereira(a)startel.pt
2009/4/9 Joao Gomes Pereira
<gomespereira(a)startel.pt>pt>:
We can spent long hours speaking about "how is it possible". What
you
should do, as I already suggested, is capturing a SIP trace with ngrep
and inspect what is happening (most probably a loop).
Just a hint: use "ngrep -d lo port 5060" to see if SIP messages are looped
klaus
Most
probably you are getting into loops. Check with ngrep the SIP
flow and you'll realize that Kamailio is sending requests to *itself*.
But how is this possible if the calls work, when placed with an Asterisk
extension?
( ex: X-Lite -> Asterisk -> Kamailio )
Kamailio should see this Asterisk as a client and
route the calls the same
way, when placed by an extension or through another Asterisk trunk.
isn't this true?
Probably, but it doesn't mean that your Kamailio config is the correct
one for that case.
Again: ngrep
Also: http://dev.sipdoc.net/wiki/ngrep-sip
6:26 p.m.
2009/4/9 Joao Gomes Pereira <gomespereira(a)startel.pt>pt>:
Hello
I did ngrep -d lo port 5060
And there are loops, because the message "513 Message too big " appears lots
of times, and always from my IP to my IP
What parts of the configuration could be creating these loops?
Obviously we don't know your configuration.
But tipically, a loop occurs when Kamailio does t_relay() and the
request leaves the proxy with the RURI unchanged (so pointed to
itself).
You must inspect the ngrep capture and determine why the request is
looped. A very basic example of looping:
route {
t_relay();
}
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
7:01 p.m.
Hello
Here is the most important part of my configuration.
What could be creating the loops? My t_relay is in the ENUM lookup...
but It should work this way.
Do I need t_relay in route[2] after forwarding to the PSTN gateway?
Thanks
Joao Pereira
route{
if (!mf_process_maxfwd_header("10")) {
sl_send_reply("483","Too Many Hops");
exit;
};
if (msg:len >= 2048 ) {
sl_send_reply("513", "Message too big");
exit;
};
# --------------------------------------------------
# PRESENCE Section
# --------------------------------------------------
if (has_totag()) {
log(3, "LOG - has_totag \n");
# sequential request withing a dialog should
# take the path determined by record-routing
if (loose_route()) {
if (is_method("BYE")) {
setflag(1); # do accounting ...
setflag(3); # ... even if the
transaction fails
}
route(1);
} else {
if (is_method("SUBSCRIBE") && uri == myself) {
# in-dialog subscribe requests
route(6);
exit;
}
if ( is_method("ACK") ) {
if ( t_check_trans() ) {
# non loose-route, but stateful
ACK; must be an A
t_relay();
exit;
} else {
# ACK without matching
transaction ... ignore and
exit;
}
}
sl_send_reply("404","Not here");
}
exit;
}
if( is_method("PUBLISH|SUBSCRIBE"))
route(6);
if (!method=="REGISTER")
record_route();
if (loose_route()) {
# mark routing logic in request
append_hf("P-hint: rr-enforced\r\n");
route(1);
};
# --------------------------------------------------
# OPTIONS Section
# --------------------------------------------------
if (method=="OPTIONS") {
options_reply();
return;
};
if (!uri==myself) {
append_hf("P-hint: outbound\r\n");
route(1);
};
# --------------------------------------------------
# Users Registration
# --------------------------------------------------
# if the request is for other domain use UsrLoc
# (in case, it does not work, use the following command
# with proper names and addresses in it)
if (uri==myself) {
if (method=="REGISTER") {
# Uncomment this if you want to use digest
authentication
if (!www_authorize("mydomain.pt",
"subscriber")) {
www_challenge("mydomain.pt", "0");
exit;
};
save("location");
exit;
};
# --------------------------------------------------
# Call Routing Section
# --------------------------------------------------
if (!lookup("location")) {
if (is_method("INVITE")) {
log(3, "LOG: CALL ROUTING - method = invite\n");
# ENUM
if ( method=="INVITE" &&
uri=~"sip:\+[1-9][0-9]*@mydomain.pt") {
if(!enum_query("e164.org.")) {
log(1, "LOG: ENUM: failed!!! :( \n");
}else{
log(1, "LOG: ENUM: query exists!!! :) \n");
if (!method=="REGISTER") record_route();
t_relay();
return;
}
}
# Route E.164 numbers to PSTN Gateway
if (uri=~"sip:\+[1-9][0-9]*@mydomain.pt" ) {
if (isflagset(29)){
# gateway 1
route(2);
return;
} else{
#gateway 2
route(3);
return;
}
}
}
}
route(1);
}
route[1] {
xlog("LOG: route 1 $ru/$du\n");
if (check_route_param("nat=yes")) {
setbflag(6);
}
if (isflagset(5) || isbflagset(6)) {
route(5);
}
t_on_reply("1");
# send it out now; use stateful forwarding as it works reliably
# even for UDP2TCP
if (!t_relay()) {
sl_reply_error();
};
exit;
}
# PSTN Gateway
route[2]
{
log(3, "LOG: route 2 \n");
if (check_route_param("nat=yes")) {
setbflag(6);
}
if (isflagset(5) || isbflagset(6)) {
route(5);
}
t_on_reply("1");
# forward to PSTN gateway
rewritehostport("gateway_IP:5060");
if (!t_relay()) {
sl_reply_error();
};
}
# Caller NAT detection route
route[4]{
log(3, "LOG: route 4 \n");
force_rport();
if (nat_uac_test("19")) {
if (method=="REGISTER") {
fix_nated_register();
} else {
fix_nated_contact();
}
setflag(5);
}
return;
}
# RTPProxy control
route[5] {
if (is_method("BYE")) {
unforce_rtp_proxy();
} else if (is_method("INVITE")){
force_rtp_proxy();
}
if (!has_totag()) add_rr_param(";nat=yes");
return;
}
onreply_route[1] {
xdbg("incoming reply\n");
if ((isflagset(5) || isbflagset(6)) &&
status=~"(183)|(2[0-9][0-9])") {
force_rtp_proxy();
}
if (isbflagset(6)) {
fix_nated_contact();
}
}
failure_route[1] {
if (is_method("INVITE")
&& (isbflagset(6) || isflagset(5))) {
unforce_rtp_proxy();
}
if (t_was_cancelled()) {
exit;
}
}
Iñaki Baz Castillo wrote:
2009/4/9 Joao Gomes Pereira
<gomespereira(a)startel.pt>pt>:
--
StarTel - A Rede Livre
Joao Gomes Pereira
www.startel.pt
+351 304500650
sip: gomespereira(a)startel.pt
Hello
I did ngrep -d lo port 5060
And there are loops, because the message "513 Message too big " appears lots
of times, and always from my IP to my IP
What parts of the configuration could be creating these loops?
Obviously we don't know your configuration.
But tipically, a loop occurs when Kamailio does t_relay() and the
request leaves the proxy with the RURI unchanged (so pointed to
itself).
You must inspect the ngrep capture and determine why the request is
looped. A very basic example of looping:
route {
t_relay();
}
8:11 p.m.
Joao Gomes Pereira wrote:
Hello
Here is the most important part of my configuration.
What could be creating the loops? My t_relay is in the ENUM lookup...
Before analyzing the config we have to find out if there is really a
loop. Have you verified with ngrep that the proxy loops the message to
itself?
but It should work this way.
Do I need t_relay in route[2] after forwarding to the PSTN gateway?
yes.
regards
klaus
PS: often seen errors:
- missing "exit" causes the message is t_relayed twice
- uri == myself fails: proxy does not detect that the RURI domain is itself
Thanks
Joao Pereira
route{
if (!mf_process_maxfwd_header("10")) {
sl_send_reply("483","Too Many Hops");
exit;
};
if (msg:len >= 2048 ) {
sl_send_reply("513", "Message too big");
exit;
};
# --------------------------------------------------
# PRESENCE Section
# --------------------------------------------------
if (has_totag()) {
log(3, "LOG - has_totag \n");
# sequential request withing a dialog should
# take the path determined by record-routing
if (loose_route()) {
if (is_method("BYE")) {
setflag(1); # do accounting ...
setflag(3); # ... even if the
transaction fails
}
route(1);
} else {
if (is_method("SUBSCRIBE") && uri == myself) {
# in-dialog subscribe requests
route(6);
exit;
}
if ( is_method("ACK") ) {
if ( t_check_trans() ) {
# non loose-route, but stateful
ACK; must be an A
t_relay();
exit;
} else {
# ACK without matching
transaction ... ignore and
exit;
}
}
sl_send_reply("404","Not here");
}
exit;
}
if( is_method("PUBLISH|SUBSCRIBE"))
route(6);
if (!method=="REGISTER")
record_route();
if (loose_route()) {
# mark routing logic in request
append_hf("P-hint: rr-enforced\r\n");
route(1);
};
# --------------------------------------------------
# OPTIONS Section
# --------------------------------------------------
if (method=="OPTIONS") {
options_reply();
return;
};
if (!uri==myself) {
append_hf("P-hint: outbound\r\n");
route(1);
};
# --------------------------------------------------
# Users Registration
# --------------------------------------------------
# if the request is for other domain use UsrLoc
# (in case, it does not work, use the following command
# with proper names and addresses in it)
if (uri==myself) {
if (method=="REGISTER") {
# Uncomment this if you want to use digest
authentication
if (!www_authorize("mydomain.pt",
"subscriber")) {
www_challenge("mydomain.pt", "0");
exit;
};
save("location");
exit;
};
# --------------------------------------------------
# Call Routing Section
# --------------------------------------------------
if (!lookup("location")) {
if (is_method("INVITE")) {
log(3, "LOG: CALL ROUTING - method = invite\n");
# ENUM
if ( method=="INVITE" &&
uri=~"sip:\+[1-9][0-9]*@mydomain.pt") {
if(!enum_query("e164.org.")) {
log(1, "LOG: ENUM: failed!!! :( \n");
}else{
log(1, "LOG: ENUM: query exists!!! :) \n");
if (!method=="REGISTER") record_route();
t_relay();
return;
}
}
# Route E.164 numbers to PSTN Gateway
if (uri=~"sip:\+[1-9][0-9]*@mydomain.pt" ) {
if (isflagset(29)){
# gateway 1
route(2);
return;
} else{
#gateway 2
route(3);
return;
}
}
}
}
route(1);
}
route[1] {
xlog("LOG: route 1 $ru/$du\n");
if (check_route_param("nat=yes")) {
setbflag(6);
}
if (isflagset(5) || isbflagset(6)) {
route(5);
}
t_on_reply("1");
# send it out now; use stateful forwarding as it works reliably
# even for UDP2TCP
if (!t_relay()) {
sl_reply_error();
};
exit;
}
# PSTN Gateway
route[2]
{
log(3, "LOG: route 2 \n");
if (check_route_param("nat=yes")) {
setbflag(6);
}
if (isflagset(5) || isbflagset(6)) {
route(5);
}
t_on_reply("1");
# forward to PSTN gateway
rewritehostport("gateway_IP:5060");
if (!t_relay()) {
sl_reply_error();
};
}
# Caller NAT detection route
route[4]{
log(3, "LOG: route 4 \n");
force_rport();
if (nat_uac_test("19")) {
if (method=="REGISTER") {
fix_nated_register();
} else {
fix_nated_contact();
}
setflag(5);
}
return;
}
# RTPProxy control
route[5] {
if (is_method("BYE")) {
unforce_rtp_proxy();
} else if (is_method("INVITE")){
force_rtp_proxy();
}
if (!has_totag()) add_rr_param(";nat=yes");
return;
}
onreply_route[1] {
xdbg("incoming reply\n");
if ((isflagset(5) || isbflagset(6)) &&
status=~"(183)|(2[0-9][0-9])") {
force_rtp_proxy();
}
if (isbflagset(6)) {
fix_nated_contact();
}
}
failure_route[1] {
if (is_method("INVITE")
&& (isbflagset(6) || isflagset(5))) {
unforce_rtp_proxy();
}
if (t_was_cancelled()) {
exit;
}
}
Iñaki Baz Castillo wrote:
2009/4/9 Joao Gomes Pereira
<gomespereira(a)startel.pt>pt>:
Hello
I did ngrep -d lo port 5060
And there are loops, because the message "513 Message too big " appears lots
of times, and always from my IP to my IP
What parts of the configuration could be creating these loops?
Obviously we don't know your configuration.
But tipically, a loop occurs when Kamailio does t_relay() and the
request leaves the proxy with the RURI unchanged (so pointed to
itself).
You must inspect the ngrep capture and determine why the request is
looped. A very basic example of looping:
route {
t_relay();
}
8:52 p.m.
Yes, I do have loops:
192.168.1.20:5060 -> 192.168.1.20:5060
NOTIFY sip:sip.startel.pt SIP/2.0..Record-Route:
<sip:192.168.1.20;lr=on;ftag=8719b3b8add4581co1>
..Record-Route:
<sip:192.168.1.20;lr=on;ftag=8719b3b8add4581co1>..Record-Route:
<sip:213.63.185.5
8;lr=on;ftag=8719b3b8add4581co1>..Record-Route:
<sip:192.168.1.20;lr=on;ftag=8719b3b8add4581co1>.
.Record-Route:
<sip:192.168.1.20;lr=on;ftag=8719b3b8add4581co1>..Record-Route:
<sip:192.168.1.20
;lr=on;ftag=8719b3b8add4581co1>..Record-Route:
<sip:192.168.1.20;lr=on;ftag=8719b3b8add4581co1>..
Record-Route:
<sip:192.168.1.20;lr=on;ftag=8719b3b8add4581co1>..Record-Route:
<sip:192.168.1.20;
lr=on;ftag=8719b3b8add4581co1>..Record-Route:
<sip:192.168.1.20;lr=on;ftag=8719b3b8add4581co1>..R
ecord-Route:
<sip:192.168.1.20;lr=on;ftag=8719b3b8add4581co1>..Record-Route:
<sip:192.168.1.20;l
r=on;ftag=8719b3b8add4581co1>..Record-Route:
<sip:192.168.1.20;lr=on;ftag=8719b3b8add4581co1>..Re
cord-Route:
<sip:192.168.1.20;lr=on;ftag=8719b3b8add4581co1>..Record-Route:
<sip:192.168.1.20;lr
=on;ftag=8719b3b8add4581co1>..Record-Route:
<sip:192.168.1.20;lr=on;ftag=8719b3b8add4581co1>..Rec
ord-Route:
<sip:192.168.1.20;lr=on;ftag=8719b3b8add4581co1>..Record-Route:
<sip:192.168.1.20;lr=
on;ftag=
Klaus Darilion wrote:
--
StarTel - A Rede Livre
Joao Gomes Pereira
www.startel.pt
+351 304500650
sip: gomespereira(a)startel.pt
Joao Gomes Pereira wrote:
Hello
Here is the most important part of my configuration.
What could be creating the loops? My t_relay is in the ENUM lookup...
Before analyzing the config we have to find out if there is really a
loop. Have you verified with ngrep that the proxy loops the message to
itself? but It should work this way.
Do I need t_relay in route[2] after forwarding to the PSTN gateway?
yes.
regards
klaus
PS: often seen errors:
- missing "exit" causes the message is t_relayed twice
- uri == myself fails: proxy does not detect that the RURI domain is
itself
Thanks
Joao Pereira
route{
if (!mf_process_maxfwd_header("10")) {
sl_send_reply("483","Too Many Hops");
exit;
};
if (msg:len >= 2048 ) {
sl_send_reply("513", "Message too big");
exit;
};
# --------------------------------------------------
# PRESENCE Section
# --------------------------------------------------
if (has_totag()) {
log(3, "LOG - has_totag \n");
# sequential request withing a dialog should
# take the path determined by record-routing
if (loose_route()) {
if (is_method("BYE")) {
setflag(1); # do accounting ...
setflag(3); # ... even if the
transaction fails
}
route(1);
} else {
if (is_method("SUBSCRIBE") && uri == myself) {
# in-dialog subscribe
requests
route(6);
exit;
}
if ( is_method("ACK") ) {
if ( t_check_trans() ) {
# non loose-route, but
stateful ACK; must be an A
t_relay();
exit;
} else {
# ACK without matching
transaction ... ignore and
exit;
}
}
sl_send_reply("404","Not here");
}
exit;
}
if( is_method("PUBLISH|SUBSCRIBE"))
route(6);
if (!method=="REGISTER")
record_route();
if (loose_route()) {
# mark routing logic in request
append_hf("P-hint: rr-enforced\r\n");
route(1);
};
# --------------------------------------------------
# OPTIONS Section
# --------------------------------------------------
if (method=="OPTIONS") {
options_reply();
return;
};
if (!uri==myself) {
append_hf("P-hint: outbound\r\n");
route(1);
};
# --------------------------------------------------
# Users Registration
# --------------------------------------------------
# if the request is for other domain use UsrLoc
# (in case, it does not work, use the following command
# with proper names and addresses in it)
if (uri==myself) {
if (method=="REGISTER") {
# Uncomment this if you want to use digest
authentication
if (!www_authorize("mydomain.pt",
"subscriber")) {
www_challenge("mydomain.pt", "0");
exit;
};
save("location");
exit;
};
# --------------------------------------------------
# Call Routing Section
# --------------------------------------------------
if (!lookup("location")) {
if (is_method("INVITE")) {
log(3, "LOG: CALL ROUTING - method = invite\n");
# ENUM
if ( method=="INVITE" &&
uri=~"sip:\+[1-9][0-9]*@mydomain.pt") {
if(!enum_query("e164.org.")) {
log(1, "LOG: ENUM: failed!!! :( \n");
}else{
log(1, "LOG: ENUM: query exists!!! :) \n");
if (!method=="REGISTER") record_route();
t_relay();
return;
}
}
# Route E.164 numbers to PSTN Gateway
if (uri=~"sip:\+[1-9][0-9]*@mydomain.pt" ) {
if (isflagset(29)){
# gateway 1
route(2);
return; } else{
#gateway 2
route(3);
return; }
}
}
}
route(1);
}
route[1] {
xlog("LOG: route 1 $ru/$du\n");
if (check_route_param("nat=yes")) {
setbflag(6);
}
if (isflagset(5) || isbflagset(6)) {
route(5);
}
t_on_reply("1");
# send it out now; use stateful forwarding as it works reliably
# even for UDP2TCP
if (!t_relay()) {
sl_reply_error();
};
exit;
}
# PSTN Gateway
route[2]
{
log(3, "LOG: route 2 \n");
if (check_route_param("nat=yes")) {
setbflag(6);
}
if (isflagset(5) || isbflagset(6)) {
route(5);
}
t_on_reply("1");
# forward to PSTN gateway
rewritehostport("gateway_IP:5060");
if (!t_relay()) {
sl_reply_error();
};
}
# Caller NAT detection route
route[4]{
log(3, "LOG: route 4 \n");
force_rport();
if (nat_uac_test("19")) {
if (method=="REGISTER") {
fix_nated_register();
} else {
fix_nated_contact();
}
setflag(5);
}
return;
}
# RTPProxy control
route[5] {
if (is_method("BYE")) {
unforce_rtp_proxy();
} else if (is_method("INVITE")){
force_rtp_proxy();
}
if (!has_totag()) add_rr_param(";nat=yes");
return;
}
onreply_route[1] {
xdbg("incoming reply\n");
if ((isflagset(5) || isbflagset(6)) &&
status=~"(183)|(2[0-9][0-9])") {
force_rtp_proxy();
}
if (isbflagset(6)) {
fix_nated_contact();
}
}
failure_route[1] {
if (is_method("INVITE")
&& (isbflagset(6) || isflagset(5))) {
unforce_rtp_proxy();
}
if (t_was_cancelled()) {
exit;
}
}
Iñaki Baz Castillo wrote:
2009/4/9 Joao Gomes Pereira
<gomespereira(a)startel.pt>pt>:
Hello
I did ngrep -d lo port 5060
And there are loops, because the message "513 Message too big "
appears lots
of times, and always from my IP to my IP
What parts of the configuration could be creating these loops?
Obviously we don't know your configuration.
But tipically, a loop occurs when Kamailio does t_relay() and the
request leaves the proxy with the RURI unchanged (so pointed to
itself).
You must inspect the ngrep capture and determine why the request is
looped. A very basic example of looping:
route {
t_relay();
}
9:28 p.m.
New subject: [Kamailio-Users] Aliases
Hello to all
Every time I start my Kamailio I get this information:
Listening on
udp: 192.168.1.20 [192.168.1.20]:5060
tcp: 192.168.1.20 [192.168.1.20]:5060
Aliases:
tcp: sip:5060
udp: sip:5060
Why do appear these aliases?
I dont have any command "aliases =" in my configuration.
Thanks
Joao Pereira
10:04 p.m.
New subject: [Kamailio-Users] Aliases
Is your hostname "sip"?
Regards,
Ovidiu Sas
On Thu, Apr 9, 2009 at 2:28 PM, Joao Gomes Pereira
<gomespereira(a)startel.pt> wrote:
Hello to all
Every time I start my Kamailio I get this information:
Listening on
udp: 192.168.1.20 [192.168.1.20]:5060
tcp: 192.168.1.20 [192.168.1.20]:5060
Aliases:
tcp: sip:5060
udp: sip:5060
Why do appear these aliases?
I dont have any command "aliases =" in my configuration.
Thanks
Joao Pereira
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
10 Apr
10 Apr
1:49 a.m.
New subject: [Kamailio-Users] Aliases
Ovidiu Sas wrote:
Is your hostname "sip"?
Regards,
Ovidiu Sas
On Thu, Apr 9, 2009 at 2:28 PM, Joao Gomes Pereira
<gomespereira(a)startel.pt> wrote:
> Hello to all
> Every time I start my Kamailio I get this information:
>
> Listening on
> udp: 192.168.1.20 [192.168.1.20]:5060
> tcp: 192.168.1.20 [192.168.1.20]:5060
> Aliases:
> tcp: sip:5060
> udp: sip:5060
>
> Why do appear these aliases?
> I dont have any command "aliases =" in my configuration.
per default Kamailio performs revers lookups for the IP address and adds
them to the alias list. If you do not like it, set auto_aliases=no (or
similar, see core cookbook)
regards
klaus
Thanks
Joao Pereira
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)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(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users 
1:07 a.m.
New subject: [Kamailio-Users] does anybody know when will be the next maintenance release for 1.5 kamailio
it looks we have found problem with nathelper and dialog, and misceneous
other things,
does anybody know when will be 1.5.0
release that get all these problem fixed ?
Jimmy
1:15 a.m.
New subject: [Kamailio-Users] carrier route vs LCR
I have been looking at the carrier route and LCR. it appears to me that LCR
can be used to handle tariff , i.e,
selecting lowest cost route. while carrier route doesn't have this
capability at all. but carrier route , according to LCR, scales better than
LCR.
for a typical telco, the rate sheet is around 5K to 20K records. it appears
both LCR and carrier route can handle it.
is the above assessment correct ?
Jinsong
2:26 a.m.
New subject: [Kamailio-Users] carrier route vs LCR
Both lcr and carrierroute can hadle routing based on price. It's just
a matter of properly defining the routed.
lcr is easier to approach then carrierroute. In 1.5 both of them are
able to cope with large number of routes.
Regards,
Ovidiu Sas
On Thu, Apr 9, 2009 at 6:15 PM, Jinsong Hu <jinsong_hu(a)hotmail.com> wrote:
I have been looking at the carrier route and LCR. it
appears to me that LCR
can be used to handle tariff , i.e,
selecting lowest cost route. while carrier route doesn't have this
capability at all. but carrier route , according to LCR, scales better than
LCR.
for a typical telco, the rate sheet is around 5K to 20K records. it appears
both LCR and carrier route can handle it.
is the above assessment correct ?
Jinsong
3:09 a.m.
New subject: [Kamailio-Users] carrier route vs LCR
by handling price, we mean that if there are 2 routes that match the same
scan_prefix, we choose the lower priced route.
in carrierroute table:
mysql> desc carrierroute;
+----------------+------------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra
|
+----------------+------------------+------+-----+---------+----------------+
| id | int(10) unsigned | NO | PRI | NULL | auto_increment
|
| carrier | int(10) unsigned | NO | | 0 |
|
| domain | int(10) unsigned | NO | | 0 |
|
| scan_prefix | varchar(64) | NO | | |
|
| flags | int(11) unsigned | NO | | 0 |
|
| mask | int(11) unsigned | NO | | 0 |
|
| prob | float | NO | | 0 |
|
| strip | int(11) unsigned | NO | | 0 |
|
| rewrite_host | varchar(128) | NO | | |
|
| rewrite_prefix | varchar(64) | NO | | |
|
| rewrite_suffix | varchar(64) | NO | | |
|
| description | varchar(255) | YES | | NULL |
|
+----------------+------------------+------+-----+---------+----------------+
we only have prob to control which route to pick up. there is no place to
store the price,
so how can we handle route based on price ?
the only way I can think of is to create another temp table, store the route
and price there,
and then select the lower priced ones and insert into carrierroute table. as
price changes,
we have to repeat this process again.
is there any other better way ?
Jimmy.
----- Original Message -----
From: "Ovidiu Sas" <osas(a)voipembedded.com>
To: "Jinsong Hu" <jinsong_hu(a)hotmail.com>
Cc: <gomespereira(a)startel.pt>pt>; <users(a)lists.kamailio.org>
Sent: Thursday, April 09, 2009 4:26 PM
Subject: Re: [Kamailio-Users] carrier route vs LCR
Both lcr and carrierroute can hadle routing based on
price. It's just
a matter of properly defining the routed.
lcr is easier to approach then carrierroute. In 1.5 both of them are
able to cope with large number of routes.
Regards,
Ovidiu Sas
On Thu, Apr 9, 2009 at 6:15 PM, Jinsong Hu <jinsong_hu(a)hotmail.com> wrote:
I have been looking at the carrier route and LCR.
it appears to me that
LCR
can be used to handle tariff , i.e,
selecting lowest cost route. while carrier route doesn't have this
capability at all. but carrier route , according to LCR, scales better
than
LCR.
for a typical telco, the rate sheet is around 5K to 20K records. it
appears
both LCR and carrier route can handle it.
is the above assessment correct ?
Jinsong
4:32 p.m.
New subject: [Kamailio-Users] carrier route vs LCR
The names in the carrierroute are a little bit confusing ...
With lcr, you route based on 'priority'.
With carierroute, you have several alternatives (take a look at
cr_route http://www.kamailio.org/docs/modules/1.5.x/carrierroute.html#id2467823):
- route inside the same 'carrier' based on 'domain' (use 'domain'
as
you would use the 'priority' inside lcr),
- route inside the same 'domain' based on 'carrier' (use
'carrier' as
you would use the 'priority' inside lcr).
With lcr, the list of GWs is done automatically, with carierroute, you
need to do it manually (by setting the right fields inside the
cr_route method).
Regards,
Ovidiu Sas
On Thu, Apr 9, 2009 at 8:09 PM, Jinsong Hu <jinsong_hu(a)hotmail.com> wrote:
by handling price, we mean that if there are 2 routes
that match the same
scan_prefix, we choose the lower priced route.
in carrierroute table:
mysql> desc carrierroute;
+----------------+------------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+----------------+------------------+------+-----+---------+----------------+
| id | int(10) unsigned | NO | PRI | NULL | auto_increment
|
| carrier | int(10) unsigned | NO | | 0 | |
| domain | int(10) unsigned | NO | | 0 | |
| scan_prefix | varchar(64) | NO | | | |
| flags | int(11) unsigned | NO | | 0 | |
| mask | int(11) unsigned | NO | | 0 | |
| prob | float | NO | | 0 | |
| strip | int(11) unsigned | NO | | 0 | |
| rewrite_host | varchar(128) | NO | | | |
| rewrite_prefix | varchar(64) | NO | | | |
| rewrite_suffix | varchar(64) | NO | | | |
| description | varchar(255) | YES | | NULL | |
+----------------+------------------+------+-----+---------+----------------+
we only have prob to control which route to pick up. there is no place to
store the price,
so how can we handle route based on price ?
the only way I can think of is to create another temp table, store the route
and price there,
and then select the lower priced ones and insert into carrierroute table. as
price changes,
we have to repeat this process again.
is there any other better way ?
Jimmy.
----- Original Message ----- From: "Ovidiu Sas" <osas(a)voipembedded.com>
To: "Jinsong Hu" <jinsong_hu(a)hotmail.com>
Cc: <gomespereira(a)startel.pt>pt>; <users(a)lists.kamailio.org>
Sent: Thursday, April 09, 2009 4:26 PM
Subject: Re: [Kamailio-Users] carrier route vs LCR
Both lcr and carrierroute can hadle routing based
on price. It's just
a matter of properly defining the routed.
lcr is easier to approach then carrierroute. In 1.5 both of them are
able to cope with large number of routes.
Regards,
Ovidiu Sas
On Thu, Apr 9, 2009 at 6:15 PM, Jinsong Hu <jinsong_hu(a)hotmail.com> wrote:
I have been looking at the carrier route and LCR. it appears to me that
LCR
can be used to handle tariff , i.e,
selecting lowest cost route. while carrier route doesn't have this
capability at all. but carrier route , according to LCR, scales better
than
LCR.
for a typical telco, the rate sheet is around 5K to 20K records. it
appears
both LCR and carrier route can handle it.
is the above assessment correct ?
Jinsong
6:55 p.m.
New subject: [Kamailio-Users] carrier route vs LCR
I am currently using LCR with 180,000 routes. I have an 8 core 2.0Ghz
system with 8GB or RAM.
On Fri, Apr 10, 2009 at 9:32 AM, Ovidiu Sas <osas(a)voipembedded.com> wrote:
The names in the carrierroute are a little bit
confusing ...
With lcr, you route based on 'priority'.
With carierroute, you have several alternatives (take a look at
cr_route http://www.kamailio.org/docs/modules/1.5.x/carrierroute.html#id2467823):
- route inside the same 'carrier' based on 'domain' (use
'domain' as
you would use the 'priority' inside lcr),
- route inside the same 'domain' based on 'carrier' (use
'carrier' as
you would use the 'priority' inside lcr).
With lcr, the list of GWs is done automatically, with carierroute, you
need to do it manually (by setting the right fields inside the
cr_route method).
Regards,
Ovidiu Sas
On Thu, Apr 9, 2009 at 8:09 PM, Jinsong Hu <jinsong_hu(a)hotmail.com> wrote:
by handling price, we mean that if there are 2
routes that match the same
scan_prefix, we choose the lower priced route.
in carrierroute table:
mysql> desc carrierroute;
+----------------+------------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+----------------+------------------+------+-----+---------+----------------+
| id | int(10) unsigned | NO | PRI | NULL | auto_increment
|
| carrier | int(10) unsigned | NO | | 0 | |
| domain | int(10) unsigned | NO | | 0 | |
| scan_prefix | varchar(64) | NO | | | |
| flags | int(11) unsigned | NO | | 0 | |
| mask | int(11) unsigned | NO | | 0 | |
| prob | float | NO | | 0 | |
| strip | int(11) unsigned | NO | | 0 | |
| rewrite_host | varchar(128) | NO | | | |
| rewrite_prefix | varchar(64) | NO | | | |
| rewrite_suffix | varchar(64) | NO | | | |
| description | varchar(255) | YES | | NULL | |
+----------------+------------------+------+-----+---------+----------------+
we only have prob to control which route to pick up. there is no place to
store the price,
so how can we handle route based on price ?
the only way I can think of is to create another temp table, store the route
and price there,
and then select the lower priced ones and insert into carrierroute table. as
price changes,
we have to repeat this process again.
is there any other better way ?
Jimmy.
----- Original Message ----- From: "Ovidiu Sas" <osas(a)voipembedded.com>
To: "Jinsong Hu" <jinsong_hu(a)hotmail.com>
Cc: <gomespereira(a)startel.pt>pt>; <users(a)lists.kamailio.org>
Sent: Thursday, April 09, 2009 4:26 PM
Subject: Re: [Kamailio-Users] carrier route vs LCR
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Both lcr and carrierroute can hadle routing based
on price. It's just
a matter of properly defining the routed.
lcr is easier to approach then carrierroute. In 1.5 both of them are
able to cope with large number of routes.
Regards,
Ovidiu Sas
On Thu, Apr 9, 2009 at 6:15 PM, Jinsong Hu <jinsong_hu(a)hotmail.com> wrote:
I have been looking at the carrier route and LCR. it appears to me that
LCR
can be used to handle tariff , i.e,
selecting lowest cost route. while carrier route doesn't have this
capability at all. but carrier route , according to LCR, scales better
than
LCR.
for a typical telco, the rate sheet is around 5K to 20K records. it
appears
both LCR and carrier route can handle it.
is the above assessment correct ?
Jinsong
7:09 p.m.
New subject: [Kamailio-Users] carrier route vs LCR
Can you provide some statistics about how the system performs?
- how many cps do you handle,
- how many workers did you configured,
- udp only or tcp and udp traffic,
- the cpu load/utilization for the config that you have.
Regards,
Ovidiu Sas
On Fri, Apr 10, 2009 at 11:55 AM, Geoffrey Mina <geoffreymina(a)gmail.com> wrote:
I am currently using LCR with 180,000 routes. I have
an 8 core 2.0Ghz
system with 8GB or RAM.
On Fri, Apr 10, 2009 at 9:32 AM, Ovidiu Sas <osas(a)voipembedded.com> wrote:
The names in the carrierroute are a little bit
confusing ...
With lcr, you route based on 'priority'.
With carierroute, you have several alternatives (take a look at
cr_route http://www.kamailio.org/docs/modules/1.5.x/carrierroute.html#id2467823):
- route inside the same 'carrier' based on 'domain' (use
'domain' as
you would use the 'priority' inside lcr),
- route inside the same 'domain' based on 'carrier' (use
'carrier' as
you would use the 'priority' inside lcr).
With lcr, the list of GWs is done automatically, with carierroute, you
need to do it manually (by setting the right fields inside the
cr_route method).
Regards,
Ovidiu Sas
On Thu, Apr 9, 2009 at 8:09 PM, Jinsong Hu <jinsong_hu(a)hotmail.com> wrote:
by handling price, we mean that if there are 2
routes that match the same
scan_prefix, we choose the lower priced route.
in carrierroute table:
mysql> desc carrierroute;
+----------------+------------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+----------------+------------------+------+-----+---------+----------------+
| id | int(10) unsigned | NO | PRI | NULL | auto_increment
|
| carrier | int(10) unsigned | NO | | 0 | |
| domain | int(10) unsigned | NO | | 0 | |
| scan_prefix | varchar(64) | NO | | | |
| flags | int(11) unsigned | NO | | 0 | |
| mask | int(11) unsigned | NO | | 0 | |
| prob | float | NO | | 0 | |
| strip | int(11) unsigned | NO | | 0 | |
| rewrite_host | varchar(128) | NO | | | |
| rewrite_prefix | varchar(64) | NO | | | |
| rewrite_suffix | varchar(64) | NO | | | |
| description | varchar(255) | YES | | NULL | |
+----------------+------------------+------+-----+---------+----------------+
we only have prob to control which route to pick up. there is no place to
store the price,
so how can we handle route based on price ?
the only way I can think of is to create another temp table, store the route
and price there,
and then select the lower priced ones and insert into carrierroute table. as
price changes,
we have to repeat this process again.
is there any other better way ?
Jimmy.
----- Original Message ----- From: "Ovidiu Sas" <osas(a)voipembedded.com>
To: "Jinsong Hu" <jinsong_hu(a)hotmail.com>
Cc: <gomespereira(a)startel.pt>pt>; <users(a)lists.kamailio.org>
Sent: Thursday, April 09, 2009 4:26 PM
Subject: Re: [Kamailio-Users] carrier route vs LCR
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Both lcr and carrierroute can hadle routing based
on price. It's just
a matter of properly defining the routed.
lcr is easier to approach then carrierroute. In 1.5 both of them are
able to cope with large number of routes.
Regards,
Ovidiu Sas
On Thu, Apr 9, 2009 at 6:15 PM, Jinsong Hu <jinsong_hu(a)hotmail.com> wrote:
>
> I have been looking at the carrier route and LCR. it appears to me that
> LCR
> can be used to handle tariff , i.e,
> selecting lowest cost route. while carrier route doesn't have this
> capability at all. but carrier route , according to LCR, scales better
> than
> LCR.
>
> for a typical telco, the rate sheet is around 5K to 20K records. it
> appears
> both LCR and carrier route can handle it.
>
> is the above assessment correct ?
>
> Jinsong
11 Apr
11 Apr
9:44 a.m.
New subject: [Kamailio-Users] using dialog to limit concurrent call, and limit monthly limits
Hi,
One of the biggest problem with VOIP service is how to defend against
unlimited usage. openning the SIP to an end user is pretty scary thing as
the following 3 things could happen:
1. people uses the same username/password for multiple phone. This is
addressed by one discussion thread in this mailing list, basically,
forwarding the traffic to the last registered AOR using
modparam("usrloc", "desc_time_order", 1)
modparam("registrar", "append_branches", 0)
2. people can use a single username/password , but uses it as a trunk, so
they run multiple channels of voice call . With this they can run up
thousands of dollars of bills on the kamailio owner. There are suggestion
that we use dialog module to limit it. However no sample code is given.
this is a sample code I googled:
if ( avp_check("$DLG_count", "gt/i:10") ) {
sl_send_reply("403","no more calls accepted");
exit;
}
but looks DLG_count is a global variable. Does any body have a better
example ?
3. even if with single channel of communication, if somebody still run the
channel in a shared environment, in theory, they can call 60*24*30
minutes=43200 minutes a month. take a cheap wholesale cost of 1 cent per
minute, this will run to $432 per month for the kamailio owner. there is no
way a voip operator can charge $432 for a user in current market. so most of
the carrier will limit
monthly usage to 2500 minutes per month. I searched kamailio modules, I
can't find any easy way
to do it. does anybody have a good solution ?
Jimmy.
12 Apr
12 Apr
6:29 a.m.
New subject: [Kamailio-Users] using dialog to limit concurrent call, and limit monthly limits
On Sat, Apr 11, 2009 at 3:44 PM, Jinsong Hu <jinsong_hu(a)hotmail.com> wrote:
2. people can use a single username/password , but
uses it as a trunk, so
they run multiple channels of voice call . With this they can run up
thousands of dollars of bills on the kamailio owner. There are suggestion
that we use dialog module to limit it. However no sample code is given.
this is a sample code I googled:
if ( avp_check("$DLG_count", "gt/i:10") ) {
sl_send_reply("403","no more calls accepted");
exit;
}
but looks DLG_count is a global variable. Does any body have a better
example ?
Hello,
here's an example limiting the number of simultaneous calls for each user:
get_profile_size("caller", "$fu", "$var(SIZE)");
if( $var(SIZE) >= MAX_NUMBER_OF_CALLS ){
sl_send_reply("503", "Simultaneous calls limit reached");
exit;
}
set_dlg_profile("caller","$fu");
15 Apr
15 Apr
6:53 a.m.
New subject: [Kamailio-Users] using dialog to limit concurrent call, and limit monthly limits
I pasted this with 1.5 kamailio, and loaded module dialog.so, the script
doesn't even work.
I suspect it is because "$var(SIZE)"
so I loaded avpops.so, it doesn't help.
I then searched http://kamailio.org/docs/modules/1.5.x/dialog.html
and found
get_profile_size("inbound_call","$avp(size)");
xlog("currently there are $avp(size) inbound calls\n");
..
get_profile_size("caller","$fu");
xlog("currently, the user %fu has $avp(size) active outgoing calls\n");
I pasted this to the script, still have problem:# /etc/init.d/kamailio
restart | grep ERRORApr 15 03:45:14 [4666] ERROR:core:main: bad config file
(4 errors)looks the problem is also $avp(size) is not defined. doesn anybody
knows how to get this solved ?Jimmy.
----- Original Message -----
From: "mayamatakeshi" <mayamatakeshi(a)gmail.com>
To: "Jinsong Hu" <jinsong_hu(a)hotmail.com>
Cc: <users(a)lists.kamailio.org>
Sent: Saturday, April 11, 2009 8:29 PM
Subject: Re: [Kamailio-Users] using dialog to limit concurrent call, and
limit monthly limits
On Sat, Apr 11, 2009 at 3:44 PM, Jinsong Hu <jinsong_hu(a)hotmail.com> wrote:
2. people can use a single username/password , but
uses it as a trunk, so
they run multiple channels of voice call . With this they can run up
thousands of dollars of bills on the kamailio owner. There are suggestion
that we use dialog module to limit it. However no sample code is given.
this is a sample code I googled:
if ( avp_check("$DLG_count", "gt/i:10") ) {
sl_send_reply("403","no more calls accepted");
exit;
}
but looks DLG_count is a global variable. Does any body have a better
example ?
Hello,
here's an example limiting the number of simultaneous calls for each user:
get_profile_size("caller", "$fu", "$var(SIZE)");
if( $var(SIZE) >= MAX_NUMBER_OF_CALLS ){
sl_send_reply("503", "Simultaneous calls limit reached");
exit;
}
set_dlg_profile("caller","$fu");
7:03 a.m.
New subject: [Kamailio-Users] using dialog to limit concurrent call, and limit monthly limits
On Wed, Apr 15, 2009 at 12:53 PM, Jinsong Hu <jinsong_hu(a)hotmail.com> wrote:
I pasted this with 1.5 kamailio, and loaded module
dialog.so, the script
doesn't even work.
I suspect it is because "$var(SIZE)"
so I loaded avpops.so, it doesn't help.
I then searched http://kamailio.org/docs/modules/1.5.x/dialog.html
and found
get_profile_size("inbound_call","$avp(size)");
xlog("currently there are $avp(size) inbound calls\n");
..
get_profile_size("caller","$fu");
xlog("currently, the user %fu has $avp(size) active outgoing calls\n");
I pasted this to the script, still have problem:# /etc/init.d/kamailio
restart | grep ERRORApr 15 03:45:14 [4666] ERROR:core:main: bad config file
(4 errors)looks the problem is also $avp(size) is not defined. doesn anybody
knows how to get this solved ?Jimmy.
Hello,
please try to put
$var(SIZE) = 0;
before the previous code snippet.
Also, be aware that I'm still using kamailio 1.4 so you may encounter
other issues as I have not tested it with 1.5.
regards,
takeshi
----- Original Message ----- From: "mayamatakeshi"
<mayamatakeshi(a)gmail.com>
To: "Jinsong Hu" <jinsong_hu(a)hotmail.com>
Cc: <users(a)lists.kamailio.org>
Sent: Saturday, April 11, 2009 8:29 PM
Subject: Re: [Kamailio-Users] using dialog to limit concurrent call, and
limit monthly limits
On Sat, Apr 11, 2009 at 3:44 PM, Jinsong Hu <jinsong_hu(a)hotmail.com> wrote:
2. people can use a single username/password , but uses it as a trunk, so
they run multiple channels of voice call . With this they can run up
thousands of dollars of bills on the kamailio owner. There are suggestion
that we use dialog module to limit it. However no sample code is given.
this is a sample code I googled:
if ( avp_check("$DLG_count", "gt/i:10") ) {
sl_send_reply("403","no more calls accepted");
exit;
}
but looks DLG_count is a global variable. Does any body have a better
example ?
Hello,
here's an example limiting the number of simultaneous calls for each user:
get_profile_size("caller", "$fu", "$var(SIZE)");
if( $var(SIZE) >= MAX_NUMBER_OF_CALLS ){
sl_send_reply("503", "Simultaneous calls limit reached");
exit;
}
set_dlg_profile("caller","$fu");
13 Apr
13 Apr
6:29 p.m.
New subject: [Kamailio-Users] using dialog to limit concurrent call, and limit monthly limits
Jinsong Hu wrote:
Hi,
One of the biggest problem with VOIP service is how to defend against
unlimited usage. openning the SIP to an end user is pretty scary thing as
the following 3 things could happen:
1. people uses the same username/password for multiple phone. This is
addressed by one discussion thread in this mailing list, basically,
forwarding the traffic to the last registered AOR using
modparam("usrloc", "desc_time_order", 1)
modparam("registrar", "append_branches", 0)
you can also use
http://www.kamailio.org/docs/modules/1.5.x/registrar.html#id2530309
with the flag 0x04
But this limits only the number of registered user. By default, also
unregistered clients can perform calls.
To allow only calls from registered clients you can verify the caller
against
http://www.kamailio.org/docs/modules/1.5.x/registrar.html#id2530856
see examples at:
http://openser.blogspot.com/2008/10/registrar-enhancements.html
2. people can use a single username/password , but
uses it as a trunk, so
they run multiple channels of voice call . With this they can run up
thousands of dollars of bills on the kamailio owner. There are suggestion
that we use dialog module to limit it. However no sample code is given.
this is a sample code I googled:
if ( avp_check("$DLG_count", "gt/i:10") ) {
sl_send_reply("403","no more calls accepted");
exit;
}
but looks DLG_count is a global variable. Does any body have a better
example ?
3. even if with single channel of communication, if somebody still run the
channel in a shared environment, in theory, they can call 60*24*30
minutes=43200 minutes a month. take a cheap wholesale cost of 1 cent per
minute, this will run to $432 per month for the kamailio owner. there is no
way a voip operator can charge $432 for a user in current market. so most of
the carrier will limit
monthly usage to 2500 minutes per month. I searched kamailio modules, I
can't find any easy way
to do it. does anybody have a good solution ?
This is something the SIP proxy can not prevent. The SIP proxy is just
the "switch". You further need a billing system which rates the calls
and also - if a user exceeds a certain limit - locks the user's account.
And for every call setup, the SIP proxy does not only verify the
password, but also "asks" the billing system if the user is allowed to
perform phone calls.
regards
klaus
Jimmy.
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
10 Apr
10 Apr
8:07 a.m.
New subject: [Kamailio-Users] carrier route vs LCR
Jinsong Hu writes:
I have been looking at the carrier route and LCR. it
appears to me that LCR
can be used to handle tariff , i.e,
selecting lowest cost route. while carrier route doesn't have this
capability at all. but carrier route , according to LCR, scales better than
LCR.
what you mean by "according to LCR"? i'm not familiar with carrier
route, but i don't see any other scaling limits with LCR except memory
for lcr and gw entries.
perhaps carrier route does not keep its corresponding entries in memory,
but fetches them each time from database?
for a typical telco, the rate sheet is around 5K to
20K records. it appears
both LCR and carrier route can handle it.
is the above assessment correct ?
LCR should be able to handle those numbers.
-- juha
14 Apr
14 Apr
11:59 a.m.
New subject: [Kamailio-Users] carrier route vs LCR
On Friday 10 April 2009, Juha Heinanen wrote:
Hi Juha,
no, it also keeps the entries in the memory, it don't do any run-time DB
operations for normal routing. Perhaps the original poster referred to the
pre 1.5.0 state, before your refactoring of the LCR code base. I'll see if i
can update the cr README a bit.
Cheers,
Henning
I have been
looking at the carrier route and LCR. it appears to me that
LCR can be used to handle tariff , i.e,
selecting lowest cost route. while carrier route doesn't have this
capability at all. but carrier route , according to LCR, scales better
than LCR.
what you mean by "according to LCR"? i'm not familiar with carrier
route, but i don't see any other scaling limits with LCR except memory
for lcr and gw entries.
perhaps carrier route does not keep its corresponding entries in memory,
but fetches them each time from database? 
6:29 p.m.
New subject: [Kamailio-Users] carrier route vs LCR
Yes update the cr README.... That we be just peachie!!! ;^)
-----Original Message-----
From: users-bounces(a)lists.kamailio.org [mailto:users-bounces@lists.kamailio.org] On Behalf
Of Henning Westerholt
Sent: Tuesday, April 14, 2009 4:59 AM
To: users(a)lists.kamailio.org
Subject: Re: [Kamailio-Users] carrier route vs LCR
On Friday 10 April 2009, Juha Heinanen wrote:
Hi Juha,
no, it also keeps the entries in the memory, it don't do any run-time DB
operations for normal routing. Perhaps the original poster referred to the
pre 1.5.0 state, before your refactoring of the LCR code base. I'll see if i
can update the cr README a bit.
Cheers,
Henning
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.287 / Virus Database: 270.11.54/2056 - Release Date: 04/13/09 17:56:00
I have been
looking at the carrier route and LCR. it appears to me that
LCR can be used to handle tariff , i.e,
selecting lowest cost route. while carrier route doesn't have this
capability at all. but carrier route , according to LCR, scales better
than LCR.
what you mean by "according to LCR"? i'm not familiar with carrier
route, but i don't see any other scaling limits with LCR except memory
for lcr and gw entries.
perhaps carrier route does not keep its corresponding entries in memory,
but fetches them each time from database?
5:39 p.m.
New subject: [Kamailio-Users] does anybody know when will be the next maintenance release for 1.5 kamailio
On Friday 10 April 2009, Jinsong Hu wrote:
it looks we have found problem with nathelper and
dialog, and misceneous
other things,
does anybody know when will be 1.5.0
release that get all these problem fixed ?
Hi Jinsong,
do you've opened already bugs for the things you've found on our tracker [1]?
I look currently in some nathelper problem (bug #2753152), and Daniel is on
one dialog problem, i think. 1.5.0 was already released, do you refer perhaps
to a 1.5.1 release?
Cheers,
Henning
[1] https://sourceforge.net/tracker/?func=add&group_id=139143&atid=7430…
6:47 p.m.
New subject: [Kamailio-Users] does anybody know when will be the next maintenance release for 1.5 kamailio
Henning Westerholt wrote:
On Friday 10 April 2009, Jinsong Hu wrote:
You may want to check out the bug status on the issues. Once they've
been fixed, the SVN version should work for you. Instructions are on
the download page.
it looks we have found problem with nathelper and
dialog, and misceneous
other things,
does anybody know when will be 1.5.0
release that get all these problem fixed ?
Hi Jinsong,
do you've opened already bugs for the things you've found on our tracker [1]?
I look currently in some nathelper problem (bug #2753152), and Daniel is on
one dialog problem, i think. 1.5.0 was already released, do you refer perhaps
to a 1.5.1 release?
Cheers,
Henning
[1] https://sourceforge.net/tracker/?func=add&group_id=139143&atid=7430…
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
6:54 p.m.
New subject: [Kamailio-Users] does anybody know when will be the next maintenance release for 1.5 kamailio
Yes, release a 1.5.1 sounds like a good idea. if there are other problems,
probably it is better that
we get a single release that get all these problem fixed, so users don't
have to have multiple patches.
Jinsong
----- Original Message -----
From: "Henning Westerholt" <henning.westerholt(a)1und1.de>
To: <users(a)lists.kamailio.org>
Cc: "Jinsong Hu" <jinsong_hu(a)hotmail.com>om>;
<gomespereira(a)startel.pt>
Sent: Tuesday, April 14, 2009 7:39 AM
Subject: Re: [Kamailio-Users] does anybody know when will be the next
maintenance release for 1.5 kamailio
On Friday 10 April 2009, Jinsong Hu wrote:
it looks we have found problem with nathelper and
dialog, and misceneous
other things,
does anybody know when will be 1.5.0
release that get all these problem fixed ?
Hi Jinsong,
do you've opened already bugs for the things you've found on our tracker
[1]?
I look currently in some nathelper problem (bug #2753152), and Daniel is
on
one dialog problem, i think. 1.5.0 was already released, do you refer
perhaps
to a 1.5.1 release?
Cheers,
Henning
[1] https://sourceforge.net/tracker/?func=add&group_id=139143&atid=7430…
15 Apr
15 Apr
1:23 p.m.
New subject: [Kamailio-Users] does anybody know when will be the next maintenance release for 1.5 kamailio
On Tuesday 14 April 2009, Jinsong Hu wrote:
Yes, release a 1.5.1 sounds like a good idea. if there
are other problems,
probably it is better that
we get a single release that get all these problem fixed, so users don't
have to have multiple patches.
Hi Jinsong,
ok. Sure, we'll release a 1.5.1, probably in the next weeks. If you noticed
some bugs that you would like to be fixed please check in our tracker if they
are already reported, if not please open a new report for them.
Thanks,
Henning
5703
days inactive
5709
days old
35 comments
12 participants
participants (12)
-
Carlos A. Alvarez -
Daniel-Constantin Mierla -
Geoffrey Mina -
Henning Westerholt -
Iñaki Baz Castillo -
jh＠tutpro.com -
Jinsong Hu -
Joao Gomes Pereira -
Klaus Darilion -
mayamatakeshi -
Mik Cheez -
Ovidiu Sas