[reSIProcate] RE: InviteSession and onTerminated
OK - my goal with this email is to generate discussion in order to make a
final decision on the desired onTerminated behavior - to call or not to call
- if the Session is being torn down due to an application request.
First I'd like to point out the differences between SVN.HEAD DUM and
TelTel.Branch DUM in regards to onTerminated:
Head DUM Summary:
-----------------
onTerminated is called whenever the InviteSession is destroyed except in the
case where onForkDestroyed is called.
Thus every onNewSession should be paired either with an onTerminated or
onForkDestroyed.
TelTel DUM Summary:
-------------------
onTerminated is called whenever the InviteSession except:
- if the session ends because the application requested it via redirect,
reject or end APIs.
- if onRedirected is called - because Redirect Manager is initiating a new
Invite.
- if onForkDestroyed is called
Proposed Changes for TelTel DUM
-------------------------------
I propose changing TelTel DUM (awaiting merge to head) to the following
behaviour - that matches the current head dum more closely and will make
porting to the new dum easier:
onTerminated is called whenever the InviteSession is destroyed except:
- when onForkDestroyed is called
- if onRedirected is called - because Redirect Manager is initiating a new
Invite.
Thus every onNewSession will be paired with an onTerminated,
onForkDestroyed, or onRedirected callback.
Advantages:
- makes porting from current dum easier
- consistent matching with onNewSession
- no need to track state in App if reject() is called. Note: reject will
tear down the session if called for an Initial Invite request, but will not
tear down the session if it is called in response to a re-invite request.
- From Dereks email below : I propose renaming DialogSet::end to
DialogSet::end and have it terminate all usages as quickly as possible.
This is the motivation for having onTerminanted called whenever an
InviteSession is destroyed; without this, the app has no easy way to clean
up state associated with usages.
for more info on Advantages see below...
Thanks,
Scott
-----Original Message-----
From: Scott Godin
Sent: Monday, December 06, 2004 4:11 PM
To: Scott Godin; 'Derek@xxxxxxxx'; 'Jason Fischl'; 'david Butcher'; 'Robert
Sparks'
Subject: RE: InviteSession and onTerminated
Another use case is the following:
An applications code to handle onOffer calls reject(488) if media in offer
is unsupported. This will either end the dialog (if rejecting an initial
invite) or return to Connected (if rejecting a reinvite request). The
application must now store state in order to know whether or not to cleanup
the call. A call to onTerminated where application cleanup logic can be put
solves this problem.
-----Original Message-----
From: Scott Godin
Sent: Thursday, December 02, 2004 2:53 PM
To: 'Derek@xxxxxxxx'; 'Jason Fischl'; 'david Butcher'; 'Robert Sparks';
Scott Godin
Subject: RE: InviteSession and onTerminated
I agree - I think there should always be an onTerminated paired with every
onNewSession. This can simplify application logic.
I also agree that DialogSet::cancel/end should always end the dialog. The
name change makes sense to me (I'll assume you meant change from
DialogSet::cancel to DialogSet::end.)
-----Original Message-----
From: Derek MacDonald [mailto:derek@xxxxxxxx]
Sent: Thursday, December 02, 2004 2:23 PM
To: 'Jason Fischl'; 'david Butcher'; 'Robert Sparks'; 'Scott Godin'
Subject: InviteSession and onTerminated
In the new InviteSession branch, onTermianted is not called when the app
calls end() on an InviteSession. It is called when a UAC is cancelled, or
when termination is not triggered by the app.
I think we should always call onTerminated, because of the following use
case:
Right now, we have DialogSet::cancel, which doesn't do the right thing if a
final response has been received(loks like it might assert in
ClientInviteSession). This is annoying race condition for an application; If
I express disinterest in a DialogSet, and before that reaches dum a final
response is processed I would just like to call cancel regardless.
I propose renaming DialogSet::end to DialogSet::end and have it terminate
all usages as quickly as possible. This is the motivation for having
onTerminanted called whenever an InviteSession is destroyed; without this,
the app has no easy way to clean up state associated with usages.
We could make it a special case that calling end on a dialogSet causes
onTerminated to be called on the InviteSession usages, but this clutters up
the code.
If we don't do this change, DialogSet::end would have to throw in some
circumstances.
--Derek