RE: [reSIProcate] DUM API question

["Derek MacDonald" <derek@xxxxxxxx>]

> -----Original Message-----
> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:resiprocate-
> devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Jason Fischl
> Sent: Tuesday, July 27, 2004 11:56 AM
> To: Derek@xxxxxxxx; 'Robert Sparks'
> Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [reSIProcate] DUM API question
> 
> 
> > Should we really create a usage from the 600(for example) if we
> > already have
> > a usage?  The application will be notified of the 600 through any
> existing
> > usages, so no information will be lost if an app wants to check where a
> > failure response came from.  Creating the additional usage makes the
> > application implementation more complicated.
> >
> > Another win is:  a request has forked to two 18x responses, and a final
> > response comes in which doesn't have the two tag of either branch. The
> > number of onTerminated calls will match the number of branches.
> >
> > If there is no usage, we have to create one.
> 
> I'm ok with this approach. In the case where there are no branches yet
> because we only received a 6xx and no 1xx what will you do?
> 

We currently create a usage in that case.  It could be argued that we
shouldn't, as it breaks the onNewSession/onTerminate symmetry.

I'm going to add a SessionProgress handler which notifies the user of
DialogSet level session progress events, so we can have ringing for
non-dialog establishing 180s.

//called when a 100 or non-dialog-establishing 18x is received for a request
virtual void onSessionSetProgress(AppDialogSetHandle, const
SipMessage&msg)=0;

Instead of creating a usage to deliver the 6xx we could add another method
to the SessionProgressHandler.

//call when a request fails w/out a dialog being established
virtual void onSessionSetupFailure(AppDialogSetHandle, const
SipMessage&msg)=0;


I'm okay with this or the Usage creation approach.  Get your votes in soon
to break the deadlock.