RE: [reSIProcate] DUM: Cancelling client session in initial state

["Derek MacDonald" <derek@xxxxxxxx>]

It doesn't...the code says change branch if the method isn't ACK or CANCEL.

> -----Original Message-----
> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:resiprocate-
> devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of kaiduan xie
> Sent: Friday, December 17, 2004 12:22 PM
> To: Derek@xxxxxxxx; 'Dmitry Semyonov'; resiprocate-
> devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [reSIProcate] DUM: Cancelling client session in initial state
> 
> Derek,
> 
> Can you clarify why DUM change branch of CANCEL and
> ACK message? Thanks.
> 
> kaiduan
>  --- Derek MacDonald <derek@xxxxxxxx> wrote:
> > DialogUsageManager::send modifies the sip message
> > in-place, so the CANCEL
> > transaction id does match. Dmitry's reference vs
> > copy explains you
> > behaviour.
> > >
> > > 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@xxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
> > > >
> > >
> >
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> > > >
> > >
> > >
> >
> ______________________________________________________________________
> > > Post your free ad now! http://personals.yahoo.ca
> > > _______________________________________________
> > > resiprocate-devel mailing list
> > > resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > >
> >
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> >
> >
> >
> 
> ______________________________________________________________________
> Post your free ad now! http://personals.yahoo.ca
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel