[reSIProcate] Re: DUM Cancel

Canh Cao canhcao at gmail.com
Sat Apr 9 20:35:53 CDT 2005


I also hit the same issue even using dum->end() method.
However, after debugging process, I found out that the
TransactionState.cxx could not find the TransactionId for the CANCEL
message.  I am not sure if it is the bug or not.  Here's my workaround
for the issue:
-- Assume you save your INIVTE request as inviteReq
-- Assume reqHandle is the handle return from onNewSession(...)

            // Create a CANCEL message from INVITE
            std::auto_ptr<SipMessage> cancelMsg(Helper::makeCancel(inviteReq));
            // Since Helper function does not set proper transaction id
            // we must reset to the current so that the state machine can
            // send the CANCEL request
            cancelMsg->header(h_Vias).front().param(p_branch).reset(
                                                inviteReq.getTransactionId());
            // Send CANCEL message                          
            reqHandle->send(canelMsg);

           // Wait for response i.e: 487

Hope this would help!

On Apr 7, 2005 9:53 PM, resiprocate-devel-request at list.sipfoundry.org
<resiprocate-devel-request at list.sipfoundry.org> wrote:
> Send resiprocate-devel mailing list submissions to
>        resiprocate-devel at list.sipfoundry.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> or, via email, send a message with subject or body 'help' to
>        resiprocate-devel-request at list.sipfoundry.org
> 
> You can reach the person managing the list at
>        resiprocate-devel-owner at list.sipfoundry.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of resiprocate-devel digest..."
> 
> 
> Today's Topics:
> 
>   1. RE: DUM Cancel (Scott Godin)
> 
> 
> 
> ---------- Forwarded message ----------
> From: Scott Godin <slgodin at icescape.com>
> To: 'prasad mahendra' <prasad at sipphone.com>
> Date: Thu, 7 Apr 2005 21:53:33 -0400
> Subject: [reSIProcate] RE: DUM Cancel
> 
> 
> You seem to be using an older version.  The latest DialogUsageManager does not contain a cancel() method - it was renamed to end().  I'm not sure if you will get the same problem or not - but it's best to see if it still happens with the latest stuff before we try to debug.
> 
>  
> ________________________________
> 
> 
> From: prasad mahendra [mailto:prasad at sipphone.com] 
> Sent: Thursday, April 07, 2005 8:59 PM
> To: Scott Godin
> Cc: resiprocate-devel at list.sipfoundry.org
> Subject: DUM Cancel
> 
>  
> 
> Resip Team, 
> 
>  
> 
> I am trying to cancel an INVITE before a dialog has been established. That is 
> 
>  
> 
> UA ---> INVITE ---> UA2 
> 
> UA <-- 100 <-------- UA2/Proxy 
> 
> UA <-- 180 <------- UA2/Proxy 
> 
>  
> 
> I did the following: 
> 
> dum->cancel( dialogSetId ). 
> 
>  
> 
> Where the dialogSetId is from the INVITE I am trying to cancel. This does not work. Is this the right way to do it? In the logs I see the CANCEL being prepared and then the dialog set being removed. Then the CANCEL results in a "481" call/txn does not exist -- almost as if these things are being done out of sequence? 
> 
>  
> 
> DEBUG | 20050407-175728.520 | SIPPAPI | RESIP:DUM | 688 | DialogId.cxx:50 | DialogId::DialogId: 3e27013a696a5d7f at RnVqaXRzdS1MYXB0b3A.-6f54ca68- 
> 
> DEBUG | 20050407-175728.520 | SIPPAPI | RESIP:DUM | 688 | DialogUsageManager.cxx:1308 | Looking for dialogSet: 3e27013a696a5d7f at RnVqaXRzdS1MYXB0b3A.-6f54ca68 in map: 
> 
> DEBUG | 20050407-175728.520 | SIPPAPI | RESIP:DUM | 688 | DialogUsageManager.cxx:1309 | [3e27013a696a5d7f at RnVqaXRzdS1MYXB0b3A.-6f54ca68 -> 04FEF1F8, 90526c5de117164e at RnVqaXRzdS1MYXB0b3A.-23690c49 -> 04FE3D80] 
> 
> DEBUG | 20050407-175728.520 | SIPPAPI | RESIP:DUM | 688 | DialogUsageManager.cxx:525 | Using outbound proxy 
> 
> DEBUG | 20050407-175728.520 | SIPPAPI | RESIP:DUM | 688 | DialogSet.cxx:112 |  ********** DialogSet::~DialogSet: 3e27013a696a5d7f at RnVqaXRzdS1MYXB0b3A.-6f54ca68************* 
> 
> DEBUG | 20050407-175728.520 | SIPPAPI | RESIP:DUM | 688 | DialogUsageManager.cxx:1339 | ************* Removing DialogSet *************** 
> 
> DEBUG | 20050407-175728.520 | SIPPAPI | RESIP:DUM | 688 | DialogUsageManager.cxx:1340 | Before: [3e27013a696a5d7f at RnVqaXRzdS1MYXB0b3A.-6f54ca68 -> 04FEF1F8, 90526c5de117164e at RnVqaXRzdS1MYXB0b3A.-23690c49 -> 04FE3D80] 
> 
> DEBUG | 20050407-175728.520 | SIPPAPI | RESIP:DUM | 688 | DialogUsageManager.cxx:1342 | After: [90526c5de117164e at RnVqaXRzdS1MYXB0b3A.-23690c49 -> 04FE3D80] 
> 
> STACK | 20050407-175728.520 | SIPPAPI | RESIP:TEST | 688 | Handled.cxx:21 | &&&&&& ~Handled 6this(04FE7430) 04FB79E0 
> 
> DEBUG | 20050407-175728.520 | SIPPAPI | RESIP:DUM | 688 | HandleManager.cxx:70 | Waiting for usages to be deleted (2) 
> 
> STACK | 20050407-175728.520 | SIPPAPI | RESIP:TRANSACTION | 2900 | TransactionState.cxx:183 | No matching transaction for SipReq:  CANCEL 17476694702 at proxy01.sipphone.com:5060 tid=48363d1607463f6c cseq=CANCEL / 1 from(tu) 
> 
> INFO | 20050407-175728.520 | SIPPAPI | RESIP:TRANSACTION | 2900 | TransactionState.cxx:265 | No matching INVITE for incoming (from TU) CANCEL to uac 
> 
> DEBUG | 20050407-175728.520 | SIPPAPI | RESIP | 2900 | Helper.cxx:272 | Helper::makeResponse(SipReq:  CANCEL 17476694702 at proxy01.sipphone.com:5060 tid=48363d1607463f6c cseq=CANCEL / 1 from(tu) code=481 reason= 
> 
> STACK | 20050407-175728.520 | SIPPAPI | RESIP:TRANSACTION | 2900 | TransactionState.cxx:1485 | Send to TU: SIP/2.0 481 Call/Transaction Does Not Exist 
> 
> To: <sip:17476694702 at proxy01.sipphone.com:5060>;tag=78550b6b 
> 
> From: <sip:17475553001 at proxy01.sipphone.com:5060>;tag=6f54ca68 
> 
> Via: SIP/2.0/ ;branch=z9hG4bK-d87543-48363d1607463f6c-1--d87543-;rport 
> 
> Call-ID: 3e27013a696a5d7f at RnVqaXRzdS1MYXB0b3A. 
> 
> CSeq: 1 CANCEL 
> 
> Content-Length: 0 
> 
>   
> 
>  
> 
> PM 
> 
>  
> 
> On Apr 5, 2005, at 4:46 PM, Scott Godin wrote: 
> 
>  
> 
> You need to add REFER as a supported Method to your MasterProfile/Profile. 
> 
>  
> 
>   
> 
>  
> 
> From: Prasad Mahendra [mailto:prasad.mahendra at sipphone.com] 
> 
> Sent: Tuesday, April 05, 2005 5:34 PM 
> 
> To: prasad mahendra; Scott Godin; engineering at sipphone.com 
> 
> Cc: resiprocate-devel at list.sipfoundry.org 
> 
> Subject: REFER (More Info) 
> 
>  
> 
>   
> 
>  
> 
> I see a "Received an unsupported method method: SipReq: REFER ...." and a few lines later "Failed RequestURI validation REFER ....". Log file reproduced below. 
> 
>  
> 
>   
> 
>  
> 
> PM/ 
> 
>  
> 
>   
> 
>  
> 
> >>>>>>>>>>>>>>>>>>>>> <<<<<<<<<<<<<<<<<<<<<<<<<<< 
> 
>  
> 
>   
> 
>  
> 
> DEBUG | 20050405-142700.658 | SIPPAPI | RESIP | 2896 | SipStack.cxx:301 | RECV: SipReq:  REFER 17475553001 at 66.27.63.248:15060 tid=146c.f1e5b312.0 cseq=REFER contact=17475553001 at proxy01.sipphone.com / 2 from(wire) 
> 
> INFO | 20050405-142700.658 | SIPPAPI | RESIP:DUM | 2896 | DialogUsageManager.cxx:663 | Got: SipReq:  REFER 17475553001 at 66.27.63.248:15060 tid=146c.f1e5b312.0 cseq=REFER contact=17475553001 at proxy01.sipphone.com / 2 from(wire) 
> 
> DEBUG | 20050405-142700.658 | SIPPAPI | RESIP:DUM | 2896 | DialogUsageManager.cxx:668 | DialogUsageManager::process: SipReq:  REFER 17475553001 at 66.27.63.248:15060 tid=146c.f1e5b312.0 cseq=REFER contact=17475553001 at proxy01.sipphone.com / 2 from(wire) 
> 
> INFO | 20050405-142700.658 | SIPPAPI | RESIP:DUM | 2896 | DialogUsageManager.cxx:865 | Received an unsupported method: SipReq:  REFER 17475553001 at 66.27.63.248:15060 tid=146c.f1e5b312.0 cseq=REFER contact=17475553001 at proxy01.sipphone.com / 2 from(wire) 
> 
> DEBUG | 20050405-142700.658 | SIPPAPI | RESIP | 2896 | Helper.cxx:272 | Helper::makeResponse(SipReq:  REFER 17475553001 at 66.27.63.248:15060 tid=146c.f1e5b312.0 cseq=REFER contact=17475553001 at proxy01.sipphone.com / 2 from(wire) code=405 reason= 
> 
> DEBUG | 20050405-142700.658 | SIPPAPI | RESIP | 2896 | SipStack.cxx:189 | SEND: SipResp: 405 tid=146c.f1e5b312.0 cseq=REFER / 2 from(tu) 
> 
> DEBUG | 20050405-142700.658 | SIPPAPI | RESIP:DUM | 2896 | DialogUsageManager.cxx:673 | Failed RequestURI validation REFER sip:17475553001 at 66.27.63.248:15060 SIP/2.0 
> 
>  
> 
> To: <sip:17475553001 at proxy01.sipphone.com>;tag=c61bd952 
> 
>  
> 
> From: <sip:SIPPHONE at proxy01.sipphone.com;tag=9494753081297.fifouacctd>;tag=db7c9c61357a18efc76e603ec3af96da-5bc6 
> 
>  
> 
> Via: SIP/2.0/UDP 198.65.166.131;branch=z9hG4bK146c.f1e5b312.0 
> 
>  
> 
> Via: SIP/2.0/UDP 198.65.166.131;branch=z9hG4bK146c.e1e5b312.0 
> 
>  
> 
> Call-ID: 9494753081297 
> 
>  
> 
> CSeq: 2 REFER 
> 
>  
> 
> Record-Route: <sip:17475553001 at 198.65.166.131;ftag=db7c9c61357a18efc76e603ec3af96da-5bc6;lr=on> 
> 
>  
> 
> Contact: <sip:17475553001 at proxy01.sipphone.com;nat=yes> 
> 
>  
> 
> Max-Forwards: 10 
> 
>  
> 
> User-Agent: Sip EXpress router(0.8.14-2 (i386/linux)) 
> 
>  
> 
> Refer-To: sip:411 at proxy01.sipphone.com 
> 
>  
> 
> Referred-By: <sip:SIPPHONE at proxy01.sipphone.com> 
> 
>  
> 
> Content-Length: 0 
> 
>  
> 
>   
> 
>  
> 
>   
> 
>  
> 
> ----- Original Message ----- 
> 
>  
> 
> From: prasad mahendra 
> 
>  
> 
> To: Scott Godin 
> 
>  
> 
> Cc: resiprocate-devel at list.sipfoundry.org 
> 
>  
> 
> Sent: Tuesday, April 05, 2005 2:22 PM 
> 
>  
> 
> Subject: [reSIProcate] REFER 
> 
>  
> 
>   
> 
>  
> 
> Resip Team, 
> 
>  
> 
> Does the resip stack support the REFER method? When I send a REFER to the resip stack it replies with a 405 method not understood/supported. 
> 
>  
> 
> PM 
> 
>  
> 
> On Mar 28, 2005, at 4:31 PM, Scott Godin wrote: 
> 
>  
> 
> Yes - I did that at the same time. 
> 
>  
> 
> -----Original Message----- 
> 
> From: Mariano Stokle [mailto:mstokle at gmail.com] 
> 
> Sent: Monday, March 28, 2005 4:46 PM 
> 
> To: Scott Godin 
> 
> Cc: jason at iii.ca; resiprocate-devel at list.sipfoundry.org; Dennis Dupont 
> 
> Subject: Re: [reSIProcate] Re: Building problem with resiprocate 0.5.0 
> 
>  
> 
> BTW, the abstract method is need to be implemented is: 
> 
>  
> 
> onRequestRetry from ClientRegistrationHandle class. I implemented an 
> 
> empty method. 
> 
>  
> 
> Regards, 
> 
> 
> 
> 
> 
> 
> On Mon, 28 Mar 2005 12:34:01 -0500, Scott Godin <slgodin at icescape.com> 
> 
> wrote: 
> 
>  
> 
> I've committed this fix - thanks. 
> 
>  
> 
> -----Original Message----- 
> 
> From: Mariano Stokle [mailto:mstokle at gmail.com] 
> 
> Sent: Sunday, March 27, 2005 5:31 PM 
> 
> To: jason at iii.ca 
> 
> Cc: resiprocate-devel at list.sipfoundry.org; Dennis Dupont 
> 
> Subject: Re: [reSIProcate] Re: Building problem with resiprocate 0.5.0 
> 
>  
> 
> Hi again, 
> 
>  
> 
> I was doing some research and got the answer. Here is the diff file: 
> 
>  
> 
> 440c440 
> 
> < auto_ptr<AppDialogSetFactory> uac_dsf(new testAppDialogSetFactory); 
> 
> --- 
> 
>  
> 
> auto_ptr<testAppDialogSetFactory> uac_dsf(new 
> 
>  
> 
> testAppDialogSetFactory); 
> 
>  
> 
> 482c482 
> 
> < auto_ptr<AppDialogSetFactory> uas_dsf(new testAppDialogSetFactory); 
> 
> --- 
> 
>  
> 
> auto_ptr<testAppDialogSetFactory> uas_dsf(new 
> 
>  
> 
> testAppDialogSetFactory); 
> 
>  
> 
> Regards, 
> 
>  
> 
> On Sun, 27 Mar 2005 18:12:00 -0300, Mariano Stokle <mstokle at gmail.com> 
> 
> wrote: 
> 
>  
> 
> Hi, 
> 
> me again. Thanks for your comments. I finally could build both 
> 
> libraries, resiprocate and dum. Test applications also worked. I am 
> 
> analysing now BasicCall.cxx. When I trie to compile, I found some 
> 
> errors with abstract functions I solved in TestUac and TestUas 
> 
> classes, but I could not figured out about this: 
> 
>  
> 
> BasicCall.cxx:428: error: no matching function for call to ` 
> 
> std::auto_ptr<resip::AppDialogSetFactory>::auto_ptr( 
> 
> std::auto_ptr<resip::AppDialogSetFactory>)' 
> 
> /usr/include/g++/memory:334: error: candidates are: 
> 
> std::auto_ptr<_Tp>::auto_ptr(std::auto_ptr_ref<_Tp>) [with _Tp = 
> 
> resip::AppDialogSetFactory] 
> 
> /usr/include/g++/memory:204: error: 
> 
> std::auto_ptr<_Tp>::auto_ptr(std::auto_ptr<_Tp1>&) [with _Tp1 = 
> 
> resip::AppDialogSetFactory, _Tp = resip::AppDialogSetFactory] 
> 
> /usr/include/g++/memory:192: error: 
> 
> std::auto_ptr<_Tp>::auto_ptr(std::auto_ptr<_Tp>&) [with _Tp = 
> 
> resip::AppDialogSetFactory] 
> 
> BasicCall.cxx:428: error: initializing argument 1 of `void 
> 
>  
> 
>   
> 
>  
> 
> resip::DialogUsageManager::setAppDialogSetFactory(std::auto_ptr<resip::AppDi 
> 
>  
> 
> alogSetFactory>) 
> 
>  
> 
> ' from result of `std::auto_ptr<_Tp>::operator std::auto_ptr<_Tp1>() 
> 
>  
> 
> [with 
> 
>  
> 
> _Tp1 = resip::AppDialogSetFactory, _Tp = testAppDialogSetFactory]' 
> 
>  
> 
> I am not an expert about auto_ptr, so I am askin for S.O.S. here. Any 
> 
> one has introduced any changes in the code to make it work? 
> 
>  
> 
> Regards, 
> 
>  
> 
> Mariano 
> 
>  
> 
> On Fri, 25 Mar 2005 08:33:37 -0800, Fischl jason 
> 
>  
> 
> <jason.fischl at gmail.com> 
> 
>  
> 
> wrote: 
> 
>  
> 
> Hi all, 
> 
>  
> 
> I think I inadvertently didn't reply my answer to the main list. The 
> 
> autotools build system is currently broken. I recommend that you use 
> 
> the default build system which can be used by just typing make. Have a 
> 
> look at sip/build/Makefile.conf if you want to customize the build 
> 
> (e.g. build shared libraries, enable IPV6, SSL, DTLS, etc.) 
> 
>  
> 
> The problem you are seeing occurs because gperf is not installed on 
> 
> your system. After installing gperf, delete the file MethodHash.cxx 
> 
> and everything will be ok. Alternatively, delete MethodHash.cxx and 
> 
> rerun svn update. The build should be fine after that. 
> 
>  
> 
> If somebody knows how to hack the Makefile to solve this problem, it 
> 
> would be great. The problem occurs because svn timestamps the files to 
> 
> the time of the checkout instead of the time of the checkin 
> 
> (differently from cvs). As a result, make decides that it needs to 
> 
> rebuild MethodHash.cxx from MethodHash.gperf. If gperf doesn't exist, 
> 
> it produces an empty file. 
> 
>  
> 
> jason 
> 
>  
> 
> On Fri, 25 Mar 2005 07:23:05 -0600, Dennis Dupont 
> 
> <ddupont at intelemedia.com> wrote: 
> 
>  
> 
> Mariano 
> 
>  
> 
> I was seeing the same problems. I started over yesterday (3/24) 
> 
>  
> 
> with 
> 
>  
> 
> a 
> 
>  
> 
> fresh copy 
> 
> from svn. This time I did *not* use autotools, I just ran make. I 
> 
>  
> 
> was 
> 
>  
> 
> able to build 
> 
> libresiprocate.a and libdum.a that way (using make -k). However, 
> 
>  
> 
> none 
> 
>  
> 
> of the test 
> 
> programs would build. I am getting the following link error: 
> 
> 
> 
> 
> 
> ../../build/../resiprocate/obj.debug.Linux.i686/libresiprocate.a(MethodT 
> 
>  
> 
> ypes.o)(.text+0x78): In function `resip::getMethodType(char const*, 
> 
> int)': 
> 
>  
> 
> /home/ddupont/devel/resiprocate-050319/main/sip/resiprocate/MethodTypes. 
> 
>  
> 
> cxx:62: undefined reference to `resip::MethodHash::in_word_set(char 
> 
> const*, unsigned)' 
> 
>  
> 
> Dennis Dupont 
> 
> Senior Systems Architect 
> 
> Intelemedia Communications, Inc. 
> 
>  
> 
> -----Original Message----- 
> 
> From: Mariano Stokle [mailto:mstokle at gmail.com] 
> 
> Sent: Thursday, March 24, 2005 7:16 PM 
> 
> To: resiprocate-devel at list.sipfoundry.org 
> 
> Subject: [reSIProcate] Re: Building problem with resiprocate 0.5.0 
> 
>  
> 
> I solved that rpoblem forcing to rebuild ARES. Now I found another: 
> 
>  
> 
> There is no relue defined to build target "Dialog.cxx" necessary for 
> 
> "Dialog.lo" 
> 
>  
> 
> Anyone with same problem? 
> 
>  
> 
> On Thu, 24 Mar 2005 18:45:04 -0300, Mariano Stokle 
> 
>  
> 
> <mstokle at gmail.com> 
> 
>  
> 
> wrote: 
> 
>  
> 
> Hi, 
> 
> I just updated resiprocate using svn to Revision 4045. I 
> 
> followed the regular procedure to build using autotools: at sip: 
> 
>  
> 
> sh use-autotools.sh 
> 
> sh autogen.sh 
> 
>  
> 
> and then at sip/compile: 
> 
> ../configure -C --enable-shared --enable-ipv6 
> 
> --enable-data-local-size=16 --disable-elog 
> 
>  
> 
> then: 
> 
> make 
> 
>  
> 
> but I got an error in AresDns.cxx 
> 
> ../../resiprocate/AresDns.cxx:12:2: #error Must have ARES 
> 
>  
> 
> I did not have this problem before..Any one had this problem? 
> 
> -- 
> 
> Mariano Stokle 
> 
> SIP Rules 
> 
>  
> 
> -- 
> 
> Mariano Stokle 
> 
> SIP Rules 
> 
>  
> 
> _______________________________________________ 
> 
> resiprocate-devel mailing list 
> 
> resiprocate-devel at list.sipfoundry.org 
> 
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel 
> 
>  
> 
>   
> 
>  
> 
> -- 
> 
> Mariano Stokle 
> 
> SIP Rules 
> 
>  
> 
> -- 
> 
> Mariano Stokle 
> 
> SIP Rules 
> 
> _______________________________________________ 
> 
> resiprocate-devel mailing list 
> 
> resiprocate-devel at list.sipfoundry.org 
> 
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel 
> 
> 
> 
> 
> 
> -- 
> 
> Mariano Stokle 
> 
> SIP Rules 
> 
>  
> 
> _______________________________________________ 
> 
> resiprocate-devel mailing list 
> 
> resiprocate-devel at list.sipfoundry.org 
> 
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel 
> 
>  
> 
> _______________________________________________ 
> 
> resiprocate-devel mailing list 
> 
> resiprocate-devel at list.sipfoundry.org 
> 
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel 
> 
> _______________________________________________ 
> 
> resiprocate-devel mailing list 
> 
> resiprocate-devel at list.sipfoundry.org 
> 
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at list.sipfoundry.org
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> 
>



More information about the resiprocate-devel mailing list