Re: [reSIProcate] Where is gone the 408 timeout ?
Hi again Scott ;)
Opps, i sent the previous message directly to you intead of the mailling
list :/
Well, i ll wait for Derek's answer and what about the "residual" dialogs ?
Is it possible to add a cancelAll method which would cancel all known
dialogs. Anyway, i dont know if it would solve the case of bogus dialogs
like the one with 408 problem since a cancel never destroys everything. I
dont know what to do about this : destroy dum even if OnDumCanBeDeleted is
never called ? If so, how long after the shutdown call ? And is it really
clean.. (memory leaks !!) ?
Regards,
Dom.
----- Original Message -----
From: "Scott Godin" <slgodin@xxxxxxxxxxxx>
To: "'Dominique Prunier'" <dominique.prunier@xxxxxxxxxxxxxxxxxx>
Sent: Wednesday, September 08, 2004 5:09 PM
Subject: RE: [reSIProcate] Where is gone the 408 timeout ?
> I agree there should be some response if don't cancel - I like the
> temporarily Dialog approach. Hopefully Derek will respond. I'll be sure
to
> forward on any private responses from him.
>
> Take care,
>
> Scott
>
>
>
> -----Original Message-----
> From: Dominique Prunier [mailto:dominique.prunier@xxxxxxxxxxxxxxxxxx]
> Sent: Wednesday, September 08, 2004 10:58 AM
> To: Scott Godin
> Subject: Re: [reSIProcate] Where is gone the 408 timeout ?
>
> Hi Scott,
>
> This problem exists even if i don't call cancel. The behaviour i would
> expect is :
> - if i invite a non existing contact and never call cancel, i expect at
> least one response at the dum level
> - if i invite a non existing contact and call cancel, i dont expect any
> further response at the dum level
> This would be pretty cool not to have to maintain another timer in
> application and use the 64*T1. At least with your fix, the AppDialogSet
will
> get destroyed and not block the shutdown but application is not notified.
> This is linked to another problem i talked few mail ago about a safe way
to
> shutdown the dum if there are some "residual" and probably bogus dialogs
not
> removed. I tried to simply remove the to tag test and it works pretty well
:
> a dialog is created with the 408 anwer and instantenly destroyed after the
> callback like any other faillure response. I dont know what is the best
way
> to handle this... There were a mail from Derek about that some times
ago...
>
> Regards,
>
> Dom.
>
> ----- Original Message -----
> From: "Scott Godin" <slgodin@xxxxxxxxxxxx>
> To: "'Dominique Prunier'" <dominique.prunier@xxxxxxxxxxxxxxxxxx>
> Sent: Wednesday, September 08, 2004 4:22 PM
> Subject: RE: [reSIProcate] Where is gone the 408 timeout ?
>
>
> > Hi Dom,
> >
> > I've also reported this to Derek - please see the attached email for my
> fix.
> > Also - you shouldn't really expect onTerminated to be called in this
> case -
> > since and InviteSession will not be created and onNewSession was never
> > called. Check out the attachment for more info...
> >
> > Scott
> >
> > -----Original Message-----
> > From: Dominique Prunier [mailto:dominique.prunier@xxxxxxxxxxxxxxxxxx]
> > Sent: Wednesday, September 08, 2004 10:13 AM
> > To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > Subject: [reSIProcate] Where is gone the 408 timeout ?
> >
> > Hello,
> >
> > I was playing with dum when, after a sip address spelling error, i
> noticied
> > that i havent got the OnTerminated callback after the timeout (408)
error.
> > After some (little) investigations, the problem seems to be that there
is
> no
> > tag in the to field of the 408. The response is not dispatched then. I
> dont
> > think this is a normal behaviour...
> >
> > dialogset.cxx:void DialogSet::dispatch(const SipMessage& msg):354
> > if(response.header(h_To).exists(p_tag))
> > {
> > break; //dialog creating/handled by dialog
> > }
> > else
> > {
> > //throw away, informational status message eventually <----- 408 go
> > there...
> > return;
> > }
> >
> > Thanks for your answer.
> > Regards,
> >
> > Dom.
> >
> > _______________________________________________
> > resiprocate-devel mailing list
> > resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> >
> >
>