[Users] looping problem

unplug maillisting at gmail.com
Thu May 11 12:13:12 CEST 2006


By analyzing the log created from ngrep, I have draft the following flow.
http://fisher.no-ip.com/ngrep/loop.log
In line 371, the looping occurs to openser itself.  I wonder why
openser loop the message itself.  Do I need to do something in dial
plan to prevent the looping?  Any simply way to prevent it?  Thanks!


UA (92)		OPENSER (228)		CISCO (215)
-----------INV------------->
<--------trying------------
			-------------INV----------->
			-------------INV----------->
			<----------trying------------
			<----------trying------------
			<----------183------------
<----------183------------
---------CANCEL--------->
			---------CANCEL--------->
<------200 canceling-------
			<---------OK---------------
			<---------487---------------
			---------ACK--------->
<----------487------------
---------CANCEL--------->
<------200 canceling-------
---------ACK--------->
---------CANCEL--------->
<------200 canceling-------
---------CANCEL--------->
		      CANCEL (looping:line 371)
		      CANCEL (looping)
		      CANCEL (looping)
		      CANCEL (looping)
		      CANCEL (looping)
		      408 (looping)		     	
			...

On 5/10/06, unplug <maillisting at gmail.com> wrote:
> 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 sr-users mailing list