[reSIProcate] DUM: Cancelling client session in initial state

[kaiduan xie]

Dmitry,

I thought the reason was:

In DialogUsageManager::send()

   if (msg.header(h_RequestLine).method() != CANCEL &&
       msg.header(h_RequestLine).method() != ACK &&
       msg.exists(h_Vias))
   {
      
msg.header(h_Vias).front().param(p_branch).reset(); 
           ^^^^^^^
   }

For example, if the initial DUM created INVITE's
branch is BranchA, after this function, the branch is
changed to BranchB and passed to transaction layer. In
transaction layer, the transaction ID is BranchB. But
for CANCEL message created in DUM, the branch is still
BranchA. So transaction layer cannot find the
corresponding INVITE transaciton!!!

Can anyone explain why the branch parameter is reset
here? Thanks,

kaiduan


 --- Dmitry Semyonov <dsemyonov at dins.ru> wrote: 
> On Fri, 5 Nov 2004, Dmitry Semyonov wrote:
> 
> > DUM does not send CANCEL request when I call end()
> method of 
> > ClientInviteSessionHandle. Also note the empty
> Contact AOR of the 
> > scheduled CANCEL request. I use r3433 based
> reSIProcate, and 
> > process(fdset).
>  [...]
> 
> Well the described behavior was caused by using
> SipMessage instance 
> instead of reference to it:
> 
> <           SipMessage is_msg =
> m_pDum->makeInviteSession( dstAor, FromAddr,
> ---
> >           // Warning! Using SipMessage instead of
> SipMessage& here will result
> >           // in wrong transaction Id!
> >           SipMessage &is_msg =
> m_pDum->makeInviteSession( dstAor, FromAddr,
> 
> -- 
> ...Bye..Dmitry.
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at list.sipfoundry.org
>
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>  

______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca