Hi Laurent, I believe you're right, we may mark the UAC transaction as "canceled" rather than deleting it right away. Unfortunatly, I have no time at the moment for implementing this...
Just out of curiosity, could you please post the complete log file showing this strange issue with the "CANCEL not being sent because no UAC transaction" issue? Cheers Raphael. Laurent Schweizer wrote: > Hi Raphael, > > > First I have done a check with PJSUA and I see that if I try to CANCEL a call > without receiving any answer of the other party, PJSUA delay the CANCEL, so I > think that we must also wait a answer. > > > Now when I check the log, I also see that sems found the transaction of the > sendet invite (UAC) > > (16512) DEBUG: ~sip_msg (sip_parser.cpp:92): ~sip_msg() > (16512) DEBUG: remove_trans (hash_table.cpp:400): ~sip_trans() > (16512) DEBUG: processEvents (AmEventQueue.cpp:72): event processed > (16512) DEBUG: run (AmSession.cpp:410): [EMAIL PROTECTED] > dlg.getUACTransPending() = 1 > (16512) DEBUG: run (AmSession.cpp:404): AmSession:: before wait for event > [EMAIL PROTECTED] > (16512) DEBUG: stopAccounting (Billing_sip.cpp:796): stopAccounting BYE from > onCancel > > > And when he don't found the transaction (just after), it's a check on > received transaction (UAS) > > 16512) DEBUG: processEvents (AmEventQueue.cpp:72): event processed > (16512) DEBUG: run (AmSession.cpp:410): f9f94848-c3c3-4721-a6bf-7a4202a363fc > dlg.getUACTransPending() = 0 > (16512) DEBUG: run (AmSession.cpp:413): dlg status = 1 > (16512) DEBUG: run (AmSession.cpp:417): dlg > 'f9f94848-c3c3-4721-a6bf-7a4202a363fc' not terminated: sending bye > (16512) DEBUG: bye (AmSipDialog.cpp:381): ignoring bye() in Pending state: no > UAC transaction to cancel. > > I don't know how exactly the transaction part in sems is working , when sems > receive a reply on UAC it's validating transaction in UAS ? > > > > I also see that reply received just after like the "100 trying" bellow don't > match anymore a transaction, so the CANCEL must also clear the UAC > transaction map. > > (16859) DEBUG: run (udp_trsp.cpp:140): recvd msg > --++-- > SIP/2.0 100 Trying > Via: SIP/2.0/UDP > 212.203.123.91:7000;received=212.203.123.91;branch=z9hG4bKEUjS1aJJ > Call-ID: [EMAIL PROTECTED] > From: <sip:[EMAIL PROTECTED]>;tag=047923E7-48AEC59C0008C78B-B730DB90 > To: <sip:[EMAIL PROTECTED]> > CSeq: 10 INVITE > Content-Length: 0 > > --++-- > (16859) DEBUG: received_msg (trans_layer.cpp:731): parse_sip_msg returned 0 > (16859) DEBUG: received_msg (trans_layer.cpp:824): Reply did NOT match any > existing transaction... > (16859) DEBUG: received_msg (trans_layer.cpp:825): reply code = 100 > (16859) DEBUG: ~sip_msg (sip_parser.cpp:92): ~sip_msg() > (16859) DEBUG: run (udp_trsp.cpp:118): before recvmsg (212.203.123.91:7000) > (16859) DEBUG: run (udp_trsp.cpp:140): recvd msg > > > > Laurent > > > > > > > > > -----Original Message----- > From: Raphael Coeffic [mailto:[EMAIL PROTECTED] > Sent: vendredi 22 août 2008 17:48 > To: Laurent Schweizer > Cc: [EMAIL PROTECTED] > Subject: Re: [Semsdev] small problem when called don't answer > > 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
