[Users] looping problem
unplug
maillisting at gmail.com
Wed May 10 13:01:22 CEST 2006
Thanks for help.
I have introduced the code below. Sometimes, I can see the logging
message "CANCEL without matching transaction ... ignore and discard"
in the log. It means it can handle the CANCAL/INVITE racing
condition. However, the looping still occured after a series of
INVITE/CANCEL operation.
route {
xlog("L_INFO","---[$fU at MR]-$rm---\n");
# -----------------------------------------------------------------
# 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;
};
#------------------------------------------------------------------
# Accounting section
#------------------------------------------------------------------
setflag(1);
# -----------------------------------------------------------------
# Record Route Section
# -----------------------------------------------------------------
if (method=="INVITE" && client_nat_test("3")) {
# INSERT YOUR IP ADDRESS HERE
record_route();
add_rr_param(";nat=yes");
} else if (method!="REGISTER") {
record_route();
};
# -----------------------------------------------------------------
# Call Tear Down Section
# do not send to voicemail if BYE or CANCEL
# is used to end call before user pickup or timeout
# -----------------------------------------------------------------
if (method=="BYE" || method=="CANCEL") {
setflag(10);
route(7);
end_media_session();
};
if (method=="PRACK") {
route(7);
};
# -----------------------------------------------------------------
# Loose Route Section
# -----------------------------------------------------------------
if (loose_route()) {
if (has_totag() && (method=="INVITE" || method=="ACK")) {
if (client_nat_test("3")||search("^Route:.*;nat=yes")){
setflag(6);
use_media_proxy();
};
};
route(1);
return;
};
# -----------------------------------------------------------------
# Call Type Processing Section
# -----------------------------------------------------------------
if (!is_uri_host_local()) {
if (is_from_local() || allow_trusted()) {
route(4);
route(1);
} else {
sl_send_reply("403", "Forbidden");
};
return;
};
if (method=="CANCEL") {
if (!t_check_trans()) {
xlog("L_WARN","---CANCEL without matching
transaction ... ignore and discard.\n");
return;
}
route(1);
return;
} else if (method=="INVITE") {
route(3);
return;
} else if (method=="REGISTER") {
route(2);
return;
} else if (method=="ACK") {
route(1);
return;
};
lookup("aliases");
if (uri!=myself) {
route(4);
route(1);
return;
};
if (!lookup("location")) {
sl_send_reply("404", "User Not Found");
return;
};
route(1);
}
On 5/8/06, samuel <samu60 at gmail.com> wrote:
> Daniel,
>
> There was a thread in serdev with title "INVITE vs. CANCEL race
> condition" talking about this issue. After that Andrei modified the tm
> to solve this issue...
>
> After re-reading that thread and what Daniel replied I could refresh
> my spoiled memory :P:
> The exact problem happens in two cases:
> *the CANCEL arrives BEFORE the INVITE, or
> *it arrives after but you are doing other high-cost processing steps
> (i.e., DNS lookup (ENUM)) before calling t_relay which will lead to
> process the CANCEL before creating the transaction.
>
> So I was not fair talking about bugs and replies (1xx) in my previous
> answers to this thread, aplogies.
>
> Samuel.
>
> 2006/5/5, Daniel-Constantin Mierla <daniel at voice-system.ro>:
> > Hello,
> >
> > On 05/05/2006 10:17 AM, samuel wrote:
> > > That's exactly what I mean and I don't know wether in 1.1 it's gonna
> > > be solved...Can any core developer shed some light on this??
> > can you give more details about this problem (web links, description ...).
> >
> > CANCEL processing is a bit delicate, if you run stateful proxy, tm
> > module takes care to forward the CANCEL to the adequate destination. But
> > if the transaction does not exists, you may end in a loop, if the CANCEL
> > processing does not follow same steps as INVITE.
> >
> > For stateful proxy, you can check if the INVITE transaction still
> > exists, and if not, drop the CANCEL, see:
> > http://openser.org/docs/modules/1.1.x/tm.html#AEN461
> >
> > Cheers,
> > Daniel
> > >
> > > The "best" way to solve this is to decrement Max-Forwards: header to a
> > > really low value (3 or 4 instead of the current minimum 16) BUT BE
> > > CAREFULL because you might have problems of failed sessions in remote
> > > proxies (it depends a lot on your topology and offered services). With
> > > this configuration your loop problem will reduce from the current 16
> > > to 3 or 4.... I repeat THIS COULD INTRODUCE INTEROPERABIOLITY
> > > issues.....use it with care.
> > >
> > > Another approach would be to increase the number of children so the
> > > probability that all openSER children get blocked is really low and
> > > the user experience is not affected. In this way you will just see
> > > from time to time the loop-effect on your logs and nothing more.
> > >
> > > I can not provide you more info...hope I was not wrong and it helped
> > > you a little....
> > >
> > > Samuel.
> > >
> > >
> > > 2006/5/5, unplug <maillisting at gmail.com>:
> > >> Thanks!
> > >> Do you mean that the CANCEL matching problem (2nd problem) may be a
> > >> bug in the openser core and may be solved in the 1.1 version? In the
> > >> mean time, any suggestion to prevent it (in setting of configuration
> > >> file) and how can you handle it?
> > >> Just to want get more information about that problem.
> > >>
> > >> On 5/4/06, samuel <samu60 at gmail.com> wrote:
> > >> > It looks like the listen and alias statement are properly configured
> > >> > and your openser will likely detect the CANCEL targeted to itself
> > >> > (check the logs).
> > >> > The "problem" is that if you do not add a port to the listen|alias
> > >> > then openSER assumes that the server is listening to all ports. This
> > >> > leads to problems when you have other SIP entities colocated to
> > >> > openSER in the same machine.
> > >> > If you do add port to the listen|alias then ONLY those ports will
> > >> > match the myself condition.
> > >> > From your config file you would match ALL ports because you have the
> > >> > alias set to 10.200.0.228.
> > >> > There was recently a thread about aliases in openser, you might find
> > >> > more info there...
> > >> > From the dokuwiki:
> > >> > "It is necessary to include the port (the value used in the "port="
> > >> > defintion) in the alias definition otherwise the loose_route()
> > >> > function will not work as expected for local forwards"
> > >> >
> > >> > So add the 5060 port to the alias and check if it is solved.
> > >> >
> > >> >
> > >> > About the second problem....it's been a long time since I last checked
> > >> > it so I might be totally wrong and the core developers should provide
> > >> > you more info. The CANCEL matching is something really inside openSER
> > >> > and requires quite changes in the core. I repeat that this might be
> > >> > solved because in SER it has been done so somebody might have ported
> > >> > it to openSER.
> > >> >
> > >> > Hope it helps,
> > >> > Samuel.
> > >>
> > >
> > > _______________________________________________
> > > Users mailing list
> > > Users at openser.org
> > > http://openser.org/cgi-bin/mailman/listinfo/users
> > >
> >
>
More information about the Users
mailing list