[Kamailio-Users] Thousands of CANCEL messages - problem with my configuration?
Raúl Alexis Betancor Santana
rabs at dimension-virtual.com
Fri Oct 9 01:11:59 CEST 2009
On Thursday 08 October 2009 22:54:24 CSB wrote:
> CANCEL sip:031234567 at domain.com SIP/2.0
> Record-Route: <sip:147.202.001.001;lr=on;ftag=as02736614>
> Record-Route: <sip:147.202.001.002;lr=on;ftag=as02736614>
> Record-Route: <sip:147.202.001.001;lr=on;ftag=as02736614>
> Record-Route: <sip:147.202.001.001;lr=on;ftag=as02736614>
> Record-Route: <sip:147.202.001.001;lr=on;ftag=as02736614>
[...]
It's obvious that you are looping over yourself. Look more about this
inline ...
> I have pasted what I think are the relevant parts from the config file.
> Could anyone advise where the problem might be?
>
> route {
>
> # -----------------------------------------------------------------
> ### SipTrace.
> # -----------------------------------------------------------------
> if ! is_method("OPTIONS|SUBSCRIBE|NOTIFY") {
> sip_trace();
> setflag(28);
> }
>
> # -----------------------------------------------------------------
> # Sanity Check Section
> # -----------------------------------------------------------------
> if (!mf_process_maxfwd_header("10")) {
> sl_send_reply("483", "Too Many Hops");
> return;
> };
>
> if (msg:len > max_len) {
> sl_send_reply("513", "Message Overflow");
> return;
> };
>
> # -----------------------------------------------------------------
> # Record Route Section
> # -----------------------------------------------------------------
> #If it's an INVITE & client is NATed,
> #xlog("welcome");
> if (method=="INVITE" && client_nat_test("3")) {
> #Record-route and specify the record-route header
> explicitly record_route_preset("147.202.001.001:5060;nat=yes"); # insert IP
> address
^^^^^^^ This is one of your biggest errors.
1º - Don't add that IP manualy, let the record_route function to decide witch
IP it's should add.
2º - You are adding a record-route header TO EVERY INVITE you receive, no
matter if a "first one" in a dialog or a reinvite, or a retrasmition, or ...
so you will allways end with a loop.
> xlog("invite and nated so record_route_preset");
> #If not Nated and not REGISTER then normal record-route
> } else if (method!="REGISTER") {
> record_route();
> xlog("not register and not nated so record_route");
> };
>
> # -----------------------------------------------------------------
> # Call Tear Down Section
> # -----------------------------------------------------------------
> if (method=="BYE" || method=="CANCEL") {
> setflag(1);
> #call end_media_session in case we're proxying media
> end_media_session();
^^^^^ So .. directly .. without checking anything more ... close
mediasessions ... you are brave !!! ;-)
> };
>
> # -----------------------------------------------------------------
> # Loose Route Section
> # -----------------------------------------------------------------
> if (loose_route()) {
> #Ensure we are dealing with a re-INVITE. Only connected
> calls have tag=
> #entry in the To header. So if it's loose routed and
> doesn't have totag
> #and it's an invite or reply then something's wrong
> xlog("loose_route");
> if ((method=="INVITE" || method=="REFER") && !has_totag())
> {
> sl_send_reply("403", "Forbidden");
> xlog("403 in lr");
> return;
> };
>
> if (method=="INVITE") {
>
> if (!allow_trusted()) {
> xlog("!allow_ trusted for r-uri <$ru>");
> if (!proxy_authorize("","subscriber")) {
> proxy_challenge("domain.com","1");
> return;
> } else if (!check_from()) {
> sl_send_reply("403", "Use
> From=ID"); return;
> };
> consume_credentials();
> };
>
> #check client is nated or that we've already
> identified it's nated
> xlog("Re-invite. rs $rs si $si rm $rm ru $ru tu $tu
> fu $fu fd $fd rr $rr");
> if (client_nat_test("3") ||
> search("^Route:.*;nat=yes")) {
> setbflag(6);
> xlog("Recipient is nated so setbflag 6 and
> use mediaproxy: r-uri <$ru>");
> use_media_proxy();
^^^^^^^ So for re-invites you take into account to do mediaproxy
handling ... but not for first-time INVITE's ... quite extrange ... ;-)
> };
>
> };
>
> route(1);
> return;
> };
>
>
> # -----------------------------------------------------------------
> # Call Type Processing Section
> # -----------------------------------------------------------------
> # Processes out-of-dialogue messages i.e.
> # 1. new dialogue
> # 2. message not destined for us (but we are relaying or proxying)
> xlog("Call Type Processing Section");
> if (!is_uri_host_local()) {
> xlog("!is_uri_host_local");
> if (is_from_local() || allow_trusted() ) {
> xlog("is_from_local() || allow_trusted()");
> route(5);
> route(1);
> } else {
> sl_send_reply("403", "Forbidden");
> xlog("403 in call type processing. rs $rs si $si rm
> $rm ru $ru tu $tu fu $fu fd $fd rr $rr");
> };
> return;
> };
>
> sip_trace();
>
> if (method=="ACK") {
> route(1);
> return;
> } else if (method=="CANCEL") {
> route(1);
^^^^^ Uff ... another point to having problems ... look ahead.
> return;
> } else if (method=="INVITE") {
> route(3);
> return;
> } else if (method=="REGISTER") {
> route(2);
> return;
> } else if (method=="SUBSCRIBE") {
> route(7);
> return;
> };
>
> route[1] {
>
> # -----------------------------------------------------------------
> # Default Message Handler
> # -----------------------------------------------------------------
>
> xlog("hit route(1). rs $rs si $si rm $rm ru $ru tu $tu fu $fu rr
> $rr");
> #Call reply_route(1) to intercept response messages heading to the
> client
> t_on_reply("1");
> #Try to relay the message to its destination
> if (!t_relay()) {
> #If it can't and it's an INVITE or ACK end the media
> proxying
> log(1,"route[1] !t_relay");
> if (method=="INVITE" || method=="ACK") {
> end_media_session();
^^^^^^ For and ACK ?? .. sure ??? .. ACK will never arrive here, also
INVITE should never arrive here, because you are sending them to route 3 from
the main route block.
> };
>
> sl_reply_error();
> } else {
> log(1,"route[1] t_relay");
> };
^^^^^ So you route CANCEL to route(1) ... but you don't test if that
CANCEL belongs to an stablished NATED dialog and close mediaproxy session ...
> }
>
> onreply_route[1]
>
> #Handles message that are returned to the sender i.e. response to caller's
> original request
> {
> xlog("hit onreply_route(1). rs $rs si $si rm $rm ru $ru tu $tu fu
> $fu rr $rr");
>
> if (isbflagset(6)) {
> xlog("flag(6) is set for $fu . We're currently in
> onreply_route(1)");
^^^^^^ So a reply to a NATED Request and you don't do
anything ... quite good ...
> };
> if (isbflagset(7)) {
> xlog("flag(7) is set for $fu . We're currently in
> onreply_route(1)");
> };
> if (status=~"(180)|(183)|2[0-9][0-9]") {
> xlog("status matches for $fu . We're currently in
> onreply_route(1)");
> };
> if ((isbflagset(6) || isbflagset(7)) &&
> (status=~"(180)|(183)|2[0-9][0-9]")) {
>
> #Check the SDP payload length. Assume if we have something
> we can call mediaproxy
> if (!search("^Content-Length:[ ]*0")) {
> log(1,"using media proxy in onreply_route(1)");
> use_media_proxy();
> };
> };
>
> if (client_nat_test("1")) {
> fix_nated_contact();
> };
^^^^^ This route-block it's a complete mess ..
> }
>
>
> Any advice appreciated.
I advice you that your confing should be rewritten, almost from scracht ...
take a look at the doc examples, because you are doing things at wild west
way ..
--
Raúl Alexis Betancor Santana
Dimensión Virtual
More information about the sr-users
mailing list