Hello,
I plan to add some rate limiting in the Kamailio. I'm already using Pike to rate limit based on the source IP.
But in this case, i want to do the rate limiting per customer(regardless of the source IP), I can identify the customer based on a custom
header in the INVITE, idea is to limit the customer to 'x' number of requests per second.
Nitesh
Hi,
I have two SIP servers, *A* and *B*, connected each other though a OPENVPN
tunnel. The server *B* needs to t_relay() every SIP message containing the
method MESSAGE to the server *A* but these messages never reach destination.
I have tested the tunnel connectivity and works fine. I wrote a Perl script
(located in *B*) that sends SIP MESSAGES to Kamailio (located in *A*) trying
to figure out what is happening but these messages are received by *A* and
processed correctly but when *B* does the same from Kamailio, it is never
received.
Here is the route part of kamailio.cfg in *B*:
Observation: ($rU == "1004") result is *true*
*
if(is_method("MESSAGE"))
{
if($rU == "1004")
{
xlog("L_INFO","En 1004");
rewritehost("10.8.0.1");
if (!t_relay())
xlog("L_INFO","MIO Error en t_relay");
t_reply("200", "Ok");
xlog("L_INFO","MIO despues rewrite");
exit;
}
.....*
The perl script that WORKS:
*$msg = 'MESSAGE sip:1004@192.168.1.2:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.2
From: "2002" <sip:2002@192.168.1.2 <sip%3A2002(a)192.168.1.2>>;tag=1837944796
To: <sip:1004@192.168.1.2 <sip%3A1004(a)192.168.1.2>>
Call-ID: 19722852989(a)192.168.1.2
CSeq: 15773 MESSAGE
Contact: <sip:2002@**PublicIP-protected**:5060>
Max-Forwards: 29
User-Agent: DBL
Content-Type: text/plain
Content-Length: 34
+595981[protected]
hello from kamailio
';
use IO::Socket;
my $sock = IO::Socket::INET->new( Proto=>'udp',
PeerHost=>'192.168.2.102',
PeerPort=>'5060');
print "Sending msg $msg\n";
$sock->send($msg) or die "error sending $!\n";
*Please help!
Thanks in advance.
Carlos.
Hi,
About 3 weeks ago i upgraded one of my production server with latest stable
kamailio version 4.2.1-fad00a. Now i am getting a lot of complaints about
missing CDR events in ACC table. I observe following problems,
1. There are only BYE records in acc table, no record for INVITE or ACK.
2. In kamailio logs when ACK is received against 200 OK response for
INVITE, i see following errors,
--
ERROR: <core> [parser/parse_from.c:113]: parse_from_uri(): failed to parse
>From uri
ERROR: pv [pv_core.c:434]: pv_get_xto_attr(): cannot parse From URI
NOTICE: <script>: [udp:<null>@1.0.0.127:5060]: Call from 'you(a)kamailio.org'
to 'you(a)kamailio.org' has been hanged up by '<null>' at '1419364717.255484'
--
Of course all these errors are bogus, I have checked all headers in ACK
(not just FROM header), they all seem perfectly fine and valid.
3. Then the dialog times out,
--
WARNING: dialog [dlg_handlers.c:1440]: dlg_ontimeout(): timeout for dlg
with CallID '6D8BD23CAC65AE3C1DE1D0B531F87B8CFEAA9CB9' and tags
'1D3ECD34F5731AB845BA3064AC95BB2D'
'7f55e81e0630-100007f-13c4-6009-2440a4-5fa31570-2440a4'
--
4. Any further sequential requests complain about "unable to find dialog",
e.g.
--
NOTICE: <script>: Sequencial 'BYE' request received from caller
ERROR: uac [replace.c:591]: restore_uri(): new URI [] shorter than old URI [
sip:00xxxxxxxxxx@sip.domain.com]
WARNING: dialog [dlg_handlers.c:1174]: dlg_onroute(): unable to find dialog
for BYE with route param '5ae1.d595' [7845:22877]
--
5. However the acc record for BYE is written to db and log file,
--
NOTICE: acc [acc.c:318]: acc_log_request(): ACC: transaction answered:
timestamp=1419364760;method=BYE;from_tag=7f55e81e0630-100007f-13c4-6009-2440a4-5fa31570-2440a4;to_tag=1D3ECD34F5731AB845BA3064AC95BB2D;call_id=6D8BD23CAC65AE3C1DE1D0B531F87B8CFEAA9CB9;code=200;reason=OK;src_user=00xxxxxxxxxx;src_domain=
sip.domain.com
;src_ip=xx.xx.xx.xx;dst_ouser=+1xxxxxxxxxx;dst_user=1xxxxxxxxxx;dst_domain=yy.yy.yy.yy
--
The same config was working fine with older version 4.2.0-97cab8. The
kamailio config i am using is pretty much standard,
--
#!define FLT_ACC 1
#!define FLT_ACCMISSED 2
#!define FLT_ACCFAILED 3
#!define FLT_DLG 4
...
modparam("acc", "early_media", 1)
modparam("acc", "report_ack", 1)
modparam("acc", "report_cancels", 1)
modparam("acc", "detect_direction", 1)
modparam("acc", "log_flag", FLT_ACC)
modparam("acc", "log_missed_flag", FLT_ACCMISSED)
modparam("acc", "failed_transaction_flag", FLT_ACCFAILED)
# log to db
modparam("acc", "db_flag", FLT_ACC)
modparam("acc", "db_missed_flag", FLT_ACCMISSED)
modparam("acc", "db_url", "DBURL")
...
request_route {
# per request initial checks
route(REQINIT);
# NAT detection
route(NATDETECT);
# handle requests within SIP dialogs
route(WITHINDLG);
# CANCEL processing
if (is_method("CANCEL")) {
if (t_check_trans()) {
t_relay();
};
exit;
};
#### only initial requests (no To tag) ####
t_check_trans();
....
# account only INVITEs
if (is_method("INVITE")) {
setflag(FLT_DLG); # create dialog
setflag(FLT_ACC); # do accounting
setflag(FLT_ACCFAILED); # ... even if the transaction fails
$avp(dlg_timeout) = 60;
dlg_manage();
....
}
--
Any ideas why its happening? Since it is 3 weeks old so may be problem has
already been spotted and fixed by someone else. Otherwise let me know how
can i provide more info to help fix this issue.
Thank you.
Hi
I am novice to kamailio , I have installed kamailio-4.2.0 and SIREMIS. I
have add and registered two IP phones with kamailio these phone able to
call each other.
How can i make outbound call with that I am using a asterisk server as PSTN
Gateway. i am not famalier with kamailio script.
Regards
Sharad Tyagi
SparkTG info Pvt Ltd
Hi,
I've a very strange scenario to work on which requires me to parallel fork
the call to the same Destination provider. The only problem here is that
they think that the second INVITE with different branch tag is a
re-transmission and hence only take one call forward.
I do not have to modify any R-URI or any headers, hence just
'append_branch() before t_relay() is in the code.
...
$ru = "sip:" + $rU + "@" + $avp(carrier_ip) + ":" + $avp(carrier_port);
append_branch();
route(RELAY);
...
*Question:* Is there anyway possible I can change the CallID of the forked
INVITEs ?
I have tried using Topoh module, but it still puts the same CallID before
sending out. Different from the A-leg but the Sent out INVITEs have same
Call-ID value.
In other weird scenario, I've also tried branching, and looping call within
Kamailio before sending out to carrier hoping that Kamailio would treat the
two different calls and Topoh would change the Call-ID on both INVITEs
before sending out..
...
if(is_present_hf("X-FORKED")) {
$ru = "sip:" + $rU + "@" + $avp(carrier_ip) + ":" + $avp(carrier_port);
route(RELAY);
}else {
append_hf("X-FORKED: 1\r\n");
append_branch();
route(RELAY);
}
...
Still I get same Call-ID on outgoing branched call.
I could branch out one INVITE to a MediaServer, say FreeSWITCH/Asterisk but
again I don't want to have that component bottleneck the throughput. That
could be my very last option.
Looking for some ideas.
Regards,
Sammy
Greetings list,
I want to keep single AOR per contact. If new regitration comes i want to
replace the old record with new.
Suppose User Alice registers from device A and after certain time it try to
register from device B. I want Registration from device B to replace A.
Any pointer is mush appreciated.
Cheers,
Aqs
Hello,
Just wondering if it's possible to intercept the bye message that
dlg_set_timeout sends out to do some nat_helper function to fix it so the
bye can be sent to random.invalid uris.
I know there is the edge proxy outbound module but wondering if I can do it
without.
Regular bye between 2 clients i was able intercept and fix with nat helper
but I dont know how to fix the byes that is sent out from dlg_set_timeout
function.
Thanks in advance!
Andrew
Hi, I have Kamailio as SIP server and RTP server. Client is PJSIP.
I read that STUN is for non-symmetric NAT, and RTP server is for symmetric
NAT.
Supposed A calls B.
If A, B both use symmetric NAT and STUN, they cannot hear each other
If A or B use non-symmetric NAT and NOT using STUN, they cannot hear each
other.
Why is that?
I read http://tools.ietf.org/id/draft-takeda-symmetric-nat-traversal-00.txt
for Prediction Failure, is that related to this problem ?
--
Khoa Pham
HCMC University of Science
Faculty of Information Technology
When I get an INVITE with Diversion Header the Request is forwarded without Diversion Header and the Request User is taken from Diversion User.
Problem is that on the Destination Host I cannot get original Request User what is the intended destination!
Is this intended behaviour? How can I change this behaviour?
I already tried to delete the Diversion Header on request_route but this didn’t change the behaviour.
Thanks in andvance for your help!
Roman
Here The INVITEs with x.x.x.x as Kamailio external IP and y.y.y.y as Carrier IP
Incoming INVITE:
INVITE sip:+43123456789@x.x.x.x:5060 SIP/2.0.
Via: SIP/2.0/UDP y.y.y.y:5060;branch=z9hG4bK02B7871714d9345f843.
From: <sip:+43987654321@y.y.y.y>;tag=gK022ac5cb.
To: <sip:436761234567@x.x.x.x>.
Call-ID: 906143813_44460603(a)y.y.y.y.
CSeq: 28100 INVITE.
Max-Forwards: 19.
Allow: INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS.
Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed.
Contact: <sip:+43987654321@y.y.y.y:5060>.
P-Asserted-Identity: <sip:+43987654321@y.y.y.y:5060>.
Diversion: <sip:+436761234567@y.y.y.y:5060>;privacy=full;screen=no; reason=unconditional; counter=1.
Supported: timer,100rel.
Session-Expires: 1800.
Min-SE: 90.
Content-Length: 260.
Content-Disposition: session; handling=required.
Content-Type: application/sdp.
...
Relayed INVITE:
INVITE sip:436761234567@x.x.x.x:5060 SIP/2.0.
Record-Route: <sip:10.23.101.1;r2=on;lr=on;ftag=gK022ac5cb>.
Record-Route: <sip:x.x.x.x;r2=on;lr=on;ftag=gK022ac5cb>.
Via: SIP/2.0/UDP 10.23.101.1;branch=z9hG4bK8582.4fc0216dbecafde29127db502993222c.0.
Via: SIP/2.0/UDP y.y.y.y:5060;rport=5060;branch=z9hG4bK02B7871714d9345f843.
From: <sip:+43987654321@y.y.y.y>;tag=gK022ac5cb.
To: <sip:436761234567@x.x.x.x>.
Call-ID: 906143813_44460603(a)y.y.y.y.
CSeq: 28100 INVITE.
Max-Forwards: 18.
Allow: INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS.
Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed.
Contact: <sip:+43987654321@y.y.y.y:5060>.
P-Asserted-Identity: <sip:+43987654321@y.y.y.y:5060>.
Supported: timer,100rel.
Session-Expires: 1800.
Min-SE: 90.
Content-Length: 274.
Content-Disposition: session; handling=required.
...
Hi all
A server running version 4.4.4+0~20161223011227 has segfaulted for the second
time this month. I'm attaching a bt in case someone can explain it to me.
cheers,
Jon
