[Users] looping problem

[samuel]

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
> >
>