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
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 wrote:
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
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
On 04/09/2009 01:07 PM, Joao Gomes Pereira wrote:
Daniel-Constantin Mierla wrote:
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
I was afraid that increasing the message length could cause some problems.... isn't it bad to have a big value like 8192?
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
2009/4/9 Joao Gomes Pereira gomespereira@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*.
Iñaki Baz Castillo wrote:
2009/4/9 Joao Gomes Pereira gomespereira@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*.
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
2009/4/9 Joao Gomes Pereira gomespereira@startel.pt:
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 )
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).
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 schrieb:
2009/4/9 Joao Gomes Pereira gomespereira@startel.pt:
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 )
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
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
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:
2009/4/9 Joao Gomes Pereira gomespereira@startel.pt:
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 )
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
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
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
2009/4/9 Joao Gomes Pereira gomespereira@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(); }
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@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(); }
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 thetransaction 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 statefulACK; 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 digestauthentication 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@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(); }
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:
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 thetransaction 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 digestauthentication 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@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(); }
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
Is your hostname "sip"?
Regards, Ovidiu Sas
On Thu, Apr 9, 2009 at 2:28 PM, Joao Gomes Pereira gomespereira@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@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Ovidiu Sas wrote:
Is your hostname "sip"?
Regards, Ovidiu Sas
On Thu, Apr 9, 2009 at 2:28 PM, Joao Gomes Pereira gomespereira@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@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@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
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
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
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@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
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@voipembedded.com To: "Jinsong Hu" jinsong_hu@hotmail.com Cc: gomespereira@startel.pt; users@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@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
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@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@voipembedded.com To: "Jinsong Hu" jinsong_hu@hotmail.com Cc: gomespereira@startel.pt; users@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@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
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@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@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@voipembedded.com To: "Jinsong Hu" jinsong_hu@hotmail.com Cc: gomespereira@startel.pt; users@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@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
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
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@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@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@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@voipembedded.com To: "Jinsong Hu" jinsong_hu@hotmail.com Cc: gomespereira@startel.pt; users@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@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
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
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.
On Sat, Apr 11, 2009 at 3:44 PM, Jinsong Hu jinsong_hu@hotmail.com wrote:
- 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");
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@gmail.com To: "Jinsong Hu" jinsong_hu@hotmail.com Cc: users@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@hotmail.com wrote:
- 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");
On Wed, Apr 15, 2009 at 12:53 PM, Jinsong Hu jinsong_hu@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@gmail.com To: "Jinsong Hu" jinsong_hu@hotmail.com Cc: users@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@hotmail.com wrote:
- 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");
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:
- 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
- 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 ?
- 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@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
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
On Friday 10 April 2009, Juha Heinanen 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.
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?
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
Yes update the cr README.... That we be just peachie!!! ;^)
-----Original Message----- From: users-bounces@lists.kamailio.org [mailto:users-bounces@lists.kamailio.org] On Behalf Of Henning Westerholt Sent: Tuesday, April 14, 2009 4:59 AM To: users@lists.kamailio.org Subject: Re: [Kamailio-Users] carrier route vs LCR
On Friday 10 April 2009, Juha Heinanen 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.
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?
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@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
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=74302...
Henning Westerholt wrote:
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=74302...
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
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.
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@1und1.de To: users@lists.kamailio.org Cc: "Jinsong Hu" jinsong_hu@hotmail.com; gomespereira@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=74302...
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
-
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