[Users] looping problem

[Daniel-Constantin Mierla]

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
>