Hi Laurent, the issue that should be investigated is: why on earth does AmSipDialog::bye pretend that there is no transaction to cancel, whereby we just sent out the INVITE?
I could think of some race condition. Something like: the INVITE is sent, and after that, the transaction is inserted in the list of UAC transactions (AmSipDialog). Another issue is: we should not send any CANCEL as long as we have not received any reply. The correct behavior would be to mark the call as "canceled", CANCEL it if we receive a provisional reply, else, if we received a final reply, we should BYE the call. Using a loop or waiting for anything in one the functions in AmSipDialog is not a good idea: it will block also the processing of other messages in the same session. -Raphael. Laurent Schweizer wrote: > Hi Raphael, > > Thanks for the solutions, now sems don't continue to send INVITE but I see a > last (I hope) problem. > > > I case of sems receive an INVITE , forward this INVTE (in b2bua mode) and > receive immediately the CANCEL, then he don't send any CANCEL to the called > party. > > I see in log: > > (16859) DEBUG: run (AmSession.cpp:415): dlg > 'a4d5d685-9af1-4a8e-a53e-67495b292a2e' not terminated: sending bye > (16859) DEBUG: bye (AmSipDialog.cpp:377): ignoring bye() in Pending state: no > UAC transaction to cancel. > > And just after I receive the "100 trying" and "183 Session in progress" , so > in this case the called party continue to ring. > > so I need to know if solution can be to implement a loop in AmSipDialog.cpp > line 377 that wait during X time that we receive back a message to correctly > send the CANCEL ? or did you have a other solutions ? > > Thanks > > Laurent > > -----Original Message----- > From: Raphael Coeffic [mailto:[EMAIL PROTECTED] > Sent: jeudi 21 août 2008 15:52 > To: Laurent Schweizer > Cc: [EMAIL PROTECTED] > Subject: Re: [Semsdev] small problem when called don't answer > > Laurent Schweizer wrote: > >> Hi Stephan, >> >> >> > I think my name 's Raphael, but anyway.... > > >> I have check my script and I call the terminateOtherLeg (); method, more >> over if I receive a message like a "183 session in progress" from the >> destination ( called party ) , I don't have this problem. >> >> >> > I think I found the issue: the status of the dialog is not set properly > by Callee session while trying to connect. Try add this after line 429 > in AmB2BSession.cpp: > dlg.status = AmSipDialog::Pending; > > -Raphael. > >> I have also tested the same scenario with sw_prepaid_sip application and I >> have the same problem. >> >> Regards >> >> Laurent >> >> -----Original Message----- >> From: Raphael Coeffic [mailto:[EMAIL PROTECTED] >> Sent: mercredi 20 août 2008 09:42 >> To: Laurent Schweizer >> Cc: [EMAIL PROTECTED] >> Subject: Re: [Semsdev] small problem when called don't answer >> >> Laurent Schweizer wrote: >> >> >>> I see that the link to pastbin was only for 1 day and was expired, so >>> I repost it >>> >>> http://pastebin.com/m5bb1920b >>> >>> >>> >>> someone has any idea to solve this problem ? >>> >>> >>> >>> >>> >> Hi Laurent, >> >> the default behavior of the B2BUA is to call onOtherBye() >> (AmB2BSession.cpp:933). onOtherBye() will call terminateLeg() >> default-wise, which will in turn terminate the other side with BYE or >> CANCEL, depending on the call state. >> >> My wild guess is that your plug-in is overloading some of those methods, >> thus by-passing the default behavior. You may have to call the default >> implementation, or re-implement it yourself, if the default >> implementation is doing additional things that you do not need/want. >> >> Cheers >> Raphael. >> >> >> >>> Thanks >>> >>> >>> >>> Laurent >>> >>> >>> >>> >>> >>> >>> >>> *From:* Laurent Schweizer >>> *Sent:* dimanche 17 août 2008 14:53 >>> *To:* '[EMAIL PROTECTED]' >>> *Subject:* small problem when called don't answer >>> >>> >>> >>> hello all, >>> >>> >>> >>> I have a problem when the called party don't send any answer, in this >>> case when the caller CANCEL the request, SEMS continues to SEND INVITE >>> to called party. >>> >>> >>> >>> and if the called party answer just after, then the call is still not >>> canceled. >>> >>> >>> >>> log of SEMS: http://pastebin.com/d72df3265 >>> >>> >>> >>> source of the code (it's a beta version ): http://ww.itvoip.ch/src.tar.gz >>> >>> >>> >>> Laurent >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Semsdev mailing list >>> [email protected] >>> http://lists.iptel.org/mailman/listinfo/semsdev >>> >>> >>> _______________________________________________ Semsdev mailing list [email protected] http://lists.iptel.org/mailman/listinfo/semsdev
