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