RE: [reSIProcate] dum behavior on call stale timeout
This was implemented slightly different from what I described below.
The onStaleCallTimeout works exactly as it did before. There is a new
overridable InviteSessionHandler::terminate() callback that will be
called immediately after onStaleCallTimeout. The default implementation
is to CANCEL the dialogset. If desired, this can be override to send
only a BYE to the timed-out leg of a forked call.
So, contrary to what I mentioned in the email below, no changes should
be necessary to current applications.
Thanks,
Scott
> -----Original Message-----
> From: Scott Godin
> Sent: Friday, October 28, 2005 3:23 PM
> To: 'Gianluca Martiniello'; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [reSIProcate] dum behavior on call stale timeout
>
> I've talk to Jason about this. Essentially the application should
decide
> if they want to just tear down one leg of a possibly forked call (BYE)
or
> all legs (CANCEL). We will change the way that the onStaleCallTimeout
> callback works. There will be a default handler that sends a BYE. If
you
> would like to send a CANCEL instead then just call handle-
> >getAppDialogSet()->end() in your overridden handler.
>
> Note: existing application will need to add a call to handle->end()
or
> InviteSessionHandler::onStaleCallTimeout(handle) in their
> onStaleCallTimeout implementations, to maintain the same functionality
as
> before this change.
>
> I'll commit the change later today.
>
> Thanks,
>
> Scott
>
> > -----Original Message-----
> > From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:resiprocate-
> > devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Gianluca Martiniello
> > Sent: Friday, October 28, 2005 12:58 PM
> > To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > Subject: Re: [reSIProcate] dum behavior on call stale timeout
> >
> > Ops, I forgot the attachment! :-D
> >
> > Gianluca Martiniello wrote:
> > > Hi all,
> > >
> > > I am using DUM to implement a simple user agent and I have noticed
> some
> > > strange behaviors exposed by DUM itself.
> > >
> > > According to the DUM documentation
> > >
> >
>
(http://www.estacado.net/resip/sip/resiprocate/doxygen/html/classresip_1
_1
> > Profile.html#a18)
> > > a call is stale if UAC gets no final response within the stale
call
> > > timeout whose default value is 3 minutes.
> > > Therefore when a call becomes stale, according to RFC 3261 a
CANCEL
> > > request should be issued (no final response has been received,
only
> one
> > > or more provisional).
> > >
> > > I have no idea of what DUM is able and what it is not able to
manage
> but
> > > as I know it is able to automatically handle registration
refreshes,
> the
> > > first time I faced the call stale condition I was expecting a
CANCEL
> > > request automatically issued by DUM. And in fact DUM, after having
> > > notified the InviteSessionHandler about stale call timeout (with
the
> > > onStaleCallTimeout() callback) automatically generated a request
but
> > > with my big surprice I saw it was a BYE request! :-|
> > >
> > > Then I decided to modify the code of my (dummy) user agent in such
a
> way
> > > that on stale call timeout event a CANCEL request was generated
(using
> > > the end() method of the associated AppDialogSet object) hoping
that
> DUM
> > > layer after having sent this message avoided to send a BYE
request.
> But
> > > again with my big surprice I saw that after the transmission of
the
> > > CANCEL request DUM issued a BYE request! :-/
> > > I have attached a log, generated with DEBUG level, which shows the
> > > behavior just described, maybe this is a bug in DUM... however if
it
> is
> > > not a bug, my question is: what should I do to correctly generate
a
> > > CANCEL request? (when I say "correctly" I mean "without having DUM
to
> > > send a BYE request")
> > >
> > > Thank you.
> > >
> > > Gianluca