Re: [reSIProcate-users] Assertion issue with StaleCallTimeout
There is nothing illegal about your step 4 below - but you are not actually ending/canceling the original invite at this point - you are only bye'ing one possible leg of a forked call. The correct way to "give up" on the call would be to use the AppDialogSet::end method. This will cause a CANCEL to be sent out, instead of a BYE.
However, since what you doing is not "illegal", DUM should not be asserting, I've made a change to ClientInviteSession::cancel - so that it will just no-op, instead of assert if it is already in the Terminated state.
Thanks,
Scott
On Thu, Jun 11, 2009 at 12:02 PM, Paul Kurmas
<pkurmas@xxxxxxxxxxxxx> wrote:
Here's the situation...
1) "A" sends an INVITE to "B".
2) "B" sends a "180 Ringing" to "A". "A" starts the stale call timer.
3) Some network error occurs that causes the "200 OK" from "B" to "A" to
be lost.
4) "A" gives up on the call, invoking ClientInviteSession::end via the
InviteSessionHandle. This transmits a BYE.
5) A few seconds later, the stale call timer fires. After our callback,
ClientInviteSession::dispatch calls InviteSessionHandler::terminate,
while in turn calls DialogSet::end. The dialog set must be non-empty
because ClientInviteSession::cancel gets called.
6) The session is not in a valid state & there's an assertion. The
application exits.
Can anyone give me an idea if our application is doing the wrong thing
to abandon the invite at this point? Or is there really a bug within
DUM or the stack?
PK
_______________________________________________
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/resiprocate-users/