Re: [reSIProcate] Session handle lifecycle question

["Kovar, William \(Bill\)" <bkovar@xxxxxxxxx>]

 Thanks for all your comments... Robert my additional comments are
inline. 

> -----Original Message-----
> From: Robert Whitaker [mailto:capnwhit@xxxxxxxxx] 
> Sent: Monday, October 16, 2006 9:37 PM
> To: Kovar, William (Bill); resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [reSIProcate] Session handle lifecycle question
> 
> Hello reSIProcate gurus,
> 
> I am replying to Bill's post, but please feel free to jump in 
> the conversation below and help me understand this better...
> 
> Hello Bill, 
> 
> Regarding your original post, I do something very similar in 
> my code and I am curious why your original code did not work 
> for you... see my comments below. 
> 
> Bill Kovar wrote: 
> >> but the handle is still valid and isTerminated() = true. 
> >> 
> As far as I know handle.isValid() should return "true" 
> because the underlying pointer should still be valid... 
> otherwise you would get a core dump (or a HandleException) if 
> you try to use the handle. In other words, the following 
> asserts should be valid inside "onTerminated":
I wasn't actually questioning the handle status, just pointing it out.
Although I am curious 'what else' may happen to that handle after it's
state is 'terminated'. 

> 
> void
> SampleUserAgent::onTerminated(resip::InviteSessionHandle 
> handle, ...) {
>   assert(handle.isValid());
>   assert(handle->isTerminated()); // This will (may) coredump 
> if previous "isValid" line returns false
>   assert(handle.get()->isTerminated()); // This is the same 
> as the previous line }
> 
> Bill Kovar wrote: 
> >> Is there somewhere ... I can look to find out if the session is no 
> >> longer valid?
> >>
> I think you were looking in the right place, inside the 
> "onTerminated" handler... in this case the *handle* will be 
> valid but the *session* will be terminated... In other words, 
> the *handle* is valid because the underlying pointer (kept by 
> DUM) is still valid, but the *session* has been terminated 
> (maybe because somebody hung up).
I'll assume that I could remove the reference of this session from my
call object without repercussions.

> 
> Bill Kovar wrote: 
> >> I stash session handles within my call management logic 
> and had hoped 
> >> that I can remove them in onTerminated()
> >> 
> QUESTION: I'm curious why you couldn't? I do something 
> similar... I stash them into a map in the "onNewSession" 
> handler and remove them inside the "onTerminated" handler... 
> Please let me know why this didn't work for you...
It's not that it didn't work, but the nature of onTerminated(), when
you're a B2B with many calls doing many things (makecall, transfer,
conference), can become rather complicated, especially in scenarios
where a call is being transferred on the back side of the B2B and the
front side (customer) hangs up!! After the original email, I re-wrote
the logic in onTerminated() and can now neatly cleanup.
BTW: Scott recommended AppDialog::getInviteSession() (DUHH!!) as the
answer to my question. Sometimes there are just too many ways to get at
things in DUM and one can get a bit lost...and blind!!

> 
> Thanks!
> 
> 
> ----- Original Message ----
> From: "Kovar, William (Bill)" <bkovar@xxxxxxxxx>
> To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> Sent: Friday, October 13, 2006 4:29:45 PM
> Subject: [reSIProcate] Session handle lifecycle question 
> 
> 
> All, 
> 
> Is there a way to know when a session has been 'disconnected' 
> from its handle, i.e. handle.isValid() == false other then to 
> check for it?? 
> 
> I stash session handles within my call management logic and 
> had hoped that I can remove them in onTerminated() but the 
> handle is still valid and isTerminated() = true. Is there 
> somewhere in the destructor of either AppDialog or 
> AppDialogSet that I can look to find out if the session is no 
> longer valid? This way I can clean my calls that this session 
> is a part of. 
> 
> Thanks 
> 
> Bill Kovar
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> 
> 
>