RE: [reSIProcate] Handling unanswered INVITE requests

[Scott Godin <slgodin@xxxxxxxxxxxx>]

Thanks Derek - unanswered invites that are not cancelled now work as
expected!!

But there is still a problem in the cancel case.  If you cancel an
unanswered invite - when the 408 eventually comes up from the stack then
this code in DialogSet::dispatch:

...
if(mCancelled)
{
        dialog->cancel();
        return;
}
else
{
        DebugLog ( << "###  Calling CreateAppDialog ### " << msg);
....

ends up calling the Dialog destructor - which tries to delete mAppDialog -
but it has never been created (or initialized) and the code traps.

Any ideas on a fix?
- we could init mAppDialog to NULL - therefor the delete would be harmless
or 
- we could create an AppDialog first

Thanks,

Scott

-----Original Message-----
From: Derek MacDonald [mailto:derek@xxxxxxxx] 
Sent: Wednesday, September 08, 2004 1:46 PM
To: 'Scott Godin'
Subject: RE: [reSIProcate] Handling unanswered INVITE requests

This is the same problem Dom was describing; lack of to tags in responses
from the stack.  I have reciprocate bracnehd at the moment(but not DUM) so I
didn't notice this glitch.

Also, I going to talk with rjs about making dum more 2543 and erroneous tag
friendly; probably post on that sometime in the next 2 weeks.

--Derek

> -----Original Message-----
> From: Scott Godin [mailto:slgodin@xxxxxxxxxxxx]
> Sent: Wednesday, September 08, 2004 7:13 AM
> To: 'Derek@xxxxxxxx'
> Subject: RE: [reSIProcate] Handling unanswered INVITE requests
> 
> Derek,
> 
> Did you get a chance to check this out, or at least verify if this is a
> bug
> or not?
> 
> I fixed it by adding the following code to DialogSet::dispatch() - but I'm
> not sure if it is 100% correct:
> 
> ...
> switch(resonse.header(h_CSeq).method())
> {
>       case INVITE:
>       case SUBSCRIBE:
>       case BYE:
>       case ACK:
>               if(response.header(h_To).exists(p_tag))
>               {
>                       break;  // dialog creating/handled by dialog
>             }
>             else
>             {
>                       //throw away, informational status message
> eventually
> *** new               if(m_Cancelled)
> *** new               {
> *** new                       guard.destroy();
> *** new               }
>                       return;
>               }
> ...
> 
> It is easily reproducible by just initiating an INVITE to a non existing
> CONTACT and don't use an outbound proxy - then call cancel() on the
> dialogset without receiving any responses.  The 488 from the stack gets
> ignored by DUM.
> 
> Thanks,
> 
> Scott
> 
> 
> -----Original Message-----
> From: Scott Godin
> Sent: Wednesday, August 18, 2004 9:57 AM
> To: 'Derek@xxxxxxxx'
> Subject: RE: [reSIProcate] Handling unanswered INVITE requests
> 
> ...
> 
> "The AppDialogSet will always be destroyed when the DialogSet is
> destroyed,
> which may be 32 seconds after cancel was called."
> 
> Odd - my AppDialogSet is never getting destroyed - even after 32 seconds.
> As a result the
>  My flow is:
> myAppDialogSet = new MyAppDialogSet(*dum, NULL));
> dum->send(dum->makeInviteSession(.., myAppDialogSet));
> ...
> myAppDialogSet->cancel();
> 
> A log is attached (where cancel was never even called - but the log is
> very
> similar) - in the code it looks like DialogSet::dispatch doesn't handle
> the
> 488 INVITE response the stack generates, since it has no To tag - I could
> be
> wrong though.
> 
> I didn't plan on going to Sipit - it's in Taipei right?  Have you ever
> been?
> Is it worth while?
> 
> I love to have a quick chat with you sometime via the phone - just to
> quickly talk about the DUM layer and your plans and timelines.  If your OK
> with this my number is 1-800-410-1051 x127 (or just say Scott) - or send
> me
> your number.
> 
> Thanks again!
> 
> Scott
> 
> 
>