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
