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 <[EMAIL PROTECTED]>:
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 <[EMAIL PROTECTED]>: >> 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 <[EMAIL PROTECTED]> 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 > [email protected] > http://openser.org/cgi-bin/mailman/listinfo/users >
_______________________________________________ Users mailing list [email protected] http://openser.org/cgi-bin/mailman/listinfo/users
