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

RE: [reSIProcate] Not using Dum but Stack Apis for the Cancel Message


Sumit

I think what Asheesh is saying is that if you use DUM at all, you 
must always use it.  But if you are sending the invite using the 
stack API, there is no reason why you should not be able to cancel 
using the same. 

Can you please clarify whether you are using DUM for anything?   
Also try logging the invite and cancel messages just before
each is sent to the stack to be sure they match.

Dennis

> -----Original Message-----
> From: Asheesh Joshi [mailto:asjoshi@xxxxxxxxxx] 
> Sent: Wednesday, September 28, 2005 7:18 AM
> To: p.sumit@xxxxxxxxx; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [reSIProcate] Not using Dum but Stack Apis for 
> the Cancel Message
> 
> 
> You must use DUM for managing dialogues. Infact that is the 
> only way you can manage dialogues in resiprocate.
> 
> -Asheesh 
> 
> -----Original Message-----
> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On 
> Behalf Of sumit
> Sent: Thursday, September 29, 2005 4:26 AM
> To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> Subject: [reSIProcate] Not using Dum but Stack Apis for the 
> Cancel Message
> 
> Hi All
> 
> I am facing a problem when I am trying to create the Cancel 
> message by using the stack APIs rather than DUM .
> Problem: Always I am receiving a 481 message with the error 
> being INFO | 20050928-154930.502 |  |  | RESIP:TRANSACTION | 
> 0 | 1079976608 | TransactionState.cxx:304 | No matching 
> INVITE for incoming (from TU) CANCEL to uac
> 
> I frame the Cancel Message in the following manner
> 
>                    DeprecatedDialog dlog(mContact);
>                     auto_ptr<SipMessage>
> cancel(dlog.makeCancel(*backupInvite) );
>                     mStack.send(*cancel);
> 
> where backupInvite is obtained from
>              
>                    backupInvite=Helper::makeInvite( target, 
> mContact, mContact);
>                    backupInvite->setContents(sdp);
> 
> Has anyone come across a similar problem?The problem on 
> analysing I feel is the sip transaction id not matching.
> 
> Regards
> Sumit
> 
> 
> _______________________________________________
> resiprocate-devel mailing list resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> 
> 
>