< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

[reSIProcate] Re: DUM Cancel


If the DUM developer can take a look at this issue it would be great!
-- I do guarantee that the following work-around would be the correct
way to do but it works in my situation:
When the CANCEL request is sent by overidding the TransactionId, DUM
immediately calls onTerminated() callback, once the callback returns,
the dialogSet also is destroyed hence the TransactionId also removed
from the map.  That's why the state machine no longer finds the dialog
for any of the subsequent response of the CANCEL request.  To address
this issue, you should not return immediately when onTerminated() is
invoked but wait until you get the 487 response.  Now this is a little
tricky to do depending on how your application's design and
architecture.


On Sun, 10 Apr 2005 11:12:28 -0700, Prasad Mahendra
<prasad.mahendra@xxxxxxxxxxxx> wrote:
> Cahn, thanks for the help.
> 
> This almost worked! Now CANCEL is sent over-the-wire but the statemachine 
> fails to recognize (find the dialog for) the 487 response and ignores it & 
> so none of the call back functions get called for me to handle this. I can 
> hack my way through and get it working (by assuming 487) but it would be 
> better if we can find a solution to this from the bottom up (find out what 
> is happening from the resip-stack/dum upwards).
> 
> --Prasad--.
> 
> 
> DEBUG | 20050410-110433.497 | SIPPAPI | RESIP:DUM | 2004 | DialogId.cxx:50 |
> 
> DialogId::DialogId: 
> 4f4b452ae118c260@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> DEBUG | 20050410-110433.497 | SIPPAPI | RESIP:DUM | 2004 | DialogSet.cxx:652
> 
> | findDialog: 
> 4f4b452ae118c260@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> 
> in []
> INFO | 20050410-110433.497 | SIPPAPI | RESIP:DUM | 2004 | DialogSet.cxx:353
> 
> | No matching dialog for
> SIP/2.0 487 Request cancelled
> To: 
> <sip:17476694702@xxxxxxxxxxxxxxxxxxxx:5060>;tag=705eb0b708230f031ff298805a9f0c33-9969
> From: <sip:17475553003@xxxxxxxxxxxxxxxxxxxx>;tag=b048392a
> Via: SIP/2.0/UDP 
> 192.168.15.100:5060;branch=z9hG4bK-d87543-d626b45c1a032f72-1--d87543-;rport=15060;received=66.27.63.248
> Call-ID: 4f4b452ae118c260@RnVqaXRzdS1MYXB0b3A.
> CSeq: 1 INVITE
> Server: Sip EXpress router (0.8.14-2 (i386/linux))
> Warning: 392 198.65.166.131:5060 "Noisy feedback tells:  pid=2371 
> req_src_ip=66.27.63.248 req_src_port=15060 
> in_uri=sip:17476694702@xxxxxxxxxxxxxxxxxxxx:5060 
> out_uri=sip:17476694702@xxxxxxxxxxxx:3848 via_cnt==1"
> Content-Length: 0
> P-Behind-NAT: Yes
> 
> 
> DEBUG | 20050410-110433.497 | SIPPAPI | RESIP:DUM | 2004 | DialogSet.cxx:587
> 
> | Creating a new Dialog from msg: SIP/2.0 487 Request cancelled
> To: 
> <sip:17476694702@xxxxxxxxxxxxxxxxxxxx:5060>;tag=705eb0b708230f031ff298805a9f0c33-9969
> From: <sip:17475553003@xxxxxxxxxxxxxxxxxxxx>;tag=b048392a
> Via: SIP/2.0/UDP 
> 192.168.15.100:5060;branch=z9hG4bK-d87543-d626b45c1a032f72-1--d87543-;rport=15060;received=66.27.63.248
> Call-ID: 4f4b452ae118c260@RnVqaXRzdS1MYXB0b3A.
> CSeq: 1 INVITE
> Server: Sip EXpress router (0.8.14-2 (i386/linux))
> Warning: 392 198.65.166.131:5060 "Noisy feedback tells:  pid=2371 
> req_src_ip=66.27.63.248 req_src_port=15060 
> in_uri=sip:17476694702@xxxxxxxxxxxxxxxxxxxx:5060 
> out_uri=sip:17476694702@xxxxxxxxxxxx:3848 via_cnt==1"
> Content-Length: 0
> P-Behind-NAT: Yes
> 
> 
> DEBUG | 20050410-110433.497 | SIPPAPI | RESIP:DUM | 2004 | DialogId.cxx:50 |
> 
> DialogId::DialogId: 
> 4f4b452ae118c260@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> DEBUG | 20050410-110433.497 | SIPPAPI | RESIP:DUM | 2004 | Dialog.cxx:197 |
> 
> ************** Created Dialog as UAC **************
> DEBUG | 20050410-110433.497 | SIPPAPI | RESIP:DUM | 2004 | Dialog.cxx:198 |
> 
> mRemoteNameAddr: 
> <sip:17476694702@xxxxxxxxxxxxxxxxxxxx:5060>;tag=705eb0b708230f031ff298805a9f0c33-9969
> DEBUG | 20050410-110433.497 | SIPPAPI | RESIP:DUM | 2004 | Dialog.cxx:199 |
> 
> mLocalNameAddr: <sip:17475553003@xxxxxxxxxxxxxxxxxxxx>;tag=b048392a
> DEBUG | 20050410-110433.497 | SIPPAPI | RESIP:DUM | 2004 | Dialog.cxx:200 |
> 
> mLocalContact: <sip:>
> DEBUG | 20050410-110433.497 | SIPPAPI | RESIP:DUM | 2004 | Dialog.cxx:201 |
> 
> mRemoteTarget: <sip:>
> DEBUG | 20050410-110433.497 | SIPPAPI | RESIP:DUM | 2004 | Dialog.cxx:206 |
> 
> Dialog::Dialog 
> 4f4b452ae118c260@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> DEBUG | 20050410-110433.497 | SIPPAPI | RESIP:DUM | 2004 | DialogSet.cxx:622
> 
> | ### Calling CreateAppDialog ### SIP/2.0 487 Request cancelled
> To: 
> <sip:17476694702@xxxxxxxxxxxxxxxxxxxx:5060>;tag=705eb0b708230f031ff298805a9f0c33-9969
> From: <sip:17475553003@xxxxxxxxxxxxxxxxxxxx>;tag=b048392a
> Via: SIP/2.0/UDP 
> 192.168.15.100:5060;branch=z9hG4bK-d87543-d626b45c1a032f72-1--d87543-;rport=15060;received=66.27.63.248
> Call-ID: 4f4b452ae118c260@RnVqaXRzdS1MYXB0b3A.
> CSeq: 1 INVITE
> Server: Sip EXpress router (0.8.14-2 (i386/linux))
> Warning: 392 198.65.166.131:5060 "Noisy feedback tells:  pid=2371 
> req_src_ip=66.27.63.248 req_src_port=15060 
> in_uri=sip:17476694702@xxxxxxxxxxxxxxxxxxxx:5060 
> out_uri=sip:17476694702@xxxxxxxxxxxx:3848 via_cnt==1"
> Content-Length: 0
> 
> 
> 
> ----- Original Message ----- 
> From: "Canh Cao" <canhcao@xxxxxxxxx>
> To: <resiprocate-devel@xxxxxxxxxxxxxxxxxxx>
> Cc: <prasad@xxxxxxxxxxxx>
> Sent: Saturday, April 09, 2005 6:35 PM
> Subject: Re: DUM Cancel
> 
> 
> >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@xxxxxxxxxxxxxxxxxxx
> > <resiprocate-devel-request@xxxxxxxxxxxxxxxxxxx> wrote:
> >> Send resiprocate-devel mailing list submissions to
> >>        resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> >>
> >> 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@xxxxxxxxxxxxxxxxxxx
> >>
> >> You can reach the person managing the list at
> >>        resiprocate-devel-owner@xxxxxxxxxxxxxxxxxxx
> >>
> >> 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@xxxxxxxxxxxx>
> >> To: 'prasad mahendra' <prasad@xxxxxxxxxxxx>
> >> 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@xxxxxxxxxxxx]
> >> Sent: Thursday, April 07, 2005 8:59 PM
> >> To: Scott Godin
> >> Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> >> 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@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> >>
> >> DEBUG | 20050407-175728.520 | SIPPAPI | RESIP:DUM | 688 | 
> >> DialogUsageManager.cxx:1308 | Looking for dialogSet: 
> >> 3e27013a696a5d7f@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx in map:
> >>
> >> DEBUG | 20050407-175728.520 | SIPPAPI | RESIP:DUM | 688 | 
> >> DialogUsageManager.cxx:1309 | 
> >> [3e27013a696a5d7f@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx -> 04FEF1F8, 
> >> 90526c5de117164e@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx -> 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@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx*************
> >>
> >> 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@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx -> 04FEF1F8, 
> >> 90526c5de117164e@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx -> 04FE3D80]
> >>
> >> DEBUG | 20050407-175728.520 | SIPPAPI | RESIP:DUM | 688 | 
> >> DialogUsageManager.cxx:1342 | After: 
> >> [90526c5de117164e@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx -> 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@xxxxxxxxxxxxxxxxxxxx: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@xxxxxxxxxxxxxxxxxxxx: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@xxxxxxxxxxxxxxxxxxxx:5060>;tag=78550b6b
> >>
> >> From: <sip:17475553001@xxxxxxxxxxxxxxxxxxxx:5060>;tag=6f54ca68
> >>
> >> Via: SIP/2.0/ ;branch=z9hG4bK-d87543-48363d1607463f6c-1--d87543-;rport
> >>
> >> Call-ID: 3e27013a696a5d7f@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@xxxxxxxxxxxx]
> >>
> >> Sent: Tuesday, April 05, 2005 5:34 PM
> >>
> >> To: prasad mahendra; Scott Godin; engineering@xxxxxxxxxxxx
> >>
> >> Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> >>
> >> 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@xxxxxxxxxxxx:15060 tid=146c.f1e5b312.0 
> >> cseq=REFER contact=17475553001@xxxxxxxxxxxxxxxxxxxx / 2 from(wire)
> >>
> >> INFO | 20050405-142700.658 | SIPPAPI | RESIP:DUM | 2896 | 
> >> DialogUsageManager.cxx:663 | Got: SipReq:  REFER 
> >> 17475553001@xxxxxxxxxxxx:15060 tid=146c.f1e5b312.0 cseq=REFER 
> >> contact=17475553001@xxxxxxxxxxxxxxxxxxxx / 2 from(wire)
> >>
> >> DEBUG | 20050405-142700.658 | SIPPAPI | RESIP:DUM | 2896 | 
> >> DialogUsageManager.cxx:668 | DialogUsageManager::process: SipReq:  REFER
> 
> >> 17475553001@xxxxxxxxxxxx:15060 tid=146c.f1e5b312.0 cseq=REFER 
> >> contact=17475553001@xxxxxxxxxxxxxxxxxxxx / 2 from(wire)
> >>
> >> INFO | 20050405-142700.658 | SIPPAPI | RESIP:DUM | 2896 | 
> >> DialogUsageManager.cxx:865 | Received an unsupported method: SipReq: 
> >> REFER 17475553001@xxxxxxxxxxxx:15060 tid=146c.f1e5b312.0 cseq=REFER 
> >> contact=17475553001@xxxxxxxxxxxxxxxxxxxx / 2 from(wire)
> >>
> >> DEBUG | 20050405-142700.658 | SIPPAPI | RESIP | 2896 | Helper.cxx:272 | 
> >> Helper::makeResponse(SipReq:  REFER 17475553001@xxxxxxxxxxxx:15060 
> >> tid=146c.f1e5b312.0 cseq=REFER contact=17475553001@xxxxxxxxxxxxxxxxxxxx /
> 
> >> 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@xxxxxxxxxxxx:15060 SIP/2.0
> >>
> >>
> >>
> >> To: <sip:17475553001@xxxxxxxxxxxxxxxxxxxx>;tag=c61bd952
> >>
> >>
> >>
> >> From: 
> >>
> <sip:SIPPHONE@xxxxxxxxxxxxxxxxxxxx;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@xxxxxxxxxxxxxx;ftag=db7c9c61357a18efc76e603ec3af96da-5bc6;lr=on>
> >>
> >>
> >>
> >> Contact: <sip:17475553001@xxxxxxxxxxxxxxxxxxxx;nat=yes>
> >>
> >>
> >>
> >> Max-Forwards: 10
> >>
> >>
> >>
> >> User-Agent: Sip EXpress router(0.8.14-2 (i386/linux))
> >>
> >>
> >>
> >> Refer-To: sip:411@xxxxxxxxxxxxxxxxxxxx
> >>
> >>
> >>
> >> Referred-By: <sip:SIPPHONE@xxxxxxxxxxxxxxxxxxxx>
> >>
> >>
> >>
> >> Content-Length: 0
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> ----- Original Message ----- 
> >>
> >>
> >>
> >> From: prasad mahendra
> >>
> >>
> >>
> >> To: Scott Godin
> >>
> >>
> >>
> >> Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> >>
> >>
> >>
> >> 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@xxxxxxxxx]
> >>
> >> Sent: Monday, March 28, 2005 4:46 PM
> >>
> >> To: Scott Godin
> >>
> >> Cc: jason@xxxxxx; resiprocate-devel@xxxxxxxxxxxxxxxxxxx; 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@xxxxxxxxxxxx>
> >>
> >> wrote:
> >>
> >>
> >>
> >> I've committed this fix - thanks.
> >>
> >>
> >>
> >> -----Original Message----- 
> >>
> >> From: Mariano Stokle [mailto:mstokle@xxxxxxxxx]
> >>
> >> Sent: Sunday, March 27, 2005 5:31 PM
> >>
> >> To: jason@xxxxxx
> >>
> >> Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx; 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@xxxxxxxxx>
> >>
> >> 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@xxxxxxxxx>
> >>
> >>
> >>
> >> 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@xxxxxxxxxxxxxxx> 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@xxxxxxxxx]
> >>
> >> Sent: Thursday, March 24, 2005 7:16 PM
> >>
> >> To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> >>
> >> 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@xxxxxxxxx>
> >>
> >>
> >>
> >> 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@xxxxxxxxxxxxxxxxxxx
> >>
> >> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> -- 
> >>
> >> Mariano Stokle
> >>
> >> SIP Rules
> >>
> >>
> >>
> >> -- 
> >>
> >> Mariano Stokle
> >>
> >> SIP Rules
> >>
> >> _______________________________________________
> >>
> >> resiprocate-devel mailing list
> >>
> >> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> >>
> >> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> >>
> >>
> >>
> >>
> >>
> >> -- 
> >>
> >> Mariano Stokle
> >>
> >> SIP Rules
> >>
> >>
> >>
> >> _______________________________________________
> >>
> >> resiprocate-devel mailing list
> >>
> >> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> >>
> >> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> >>
> >>
> >>
> >> _______________________________________________
> >>
> >> resiprocate-devel mailing list
> >>
> >> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> >>
> >> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> >>
> >> _______________________________________________
> >>
> >> resiprocate-devel mailing list
> >>
> >> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> >>
> >> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> >> _______________________________________________
> >> resiprocate-devel mailing list
> >> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> >> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> >>
> >>
> > 
> 
> 
>