RE: [reSIProcate] DUM API question

["Derek MacDonald" <derek@xxxxxxxx>]

> -----Original Message-----
> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:resiprocate-
> devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Robert Sparks
> Sent: Tuesday, July 27, 2004 10:41 AM
> To: Jason Fischl
> Cc: 'resiprocate-devel@xxxxxxxxxxxxxxxxxxx' Resiprocate
> Subject: RE: [reSIProcate] DUM API question
> 
> On Tue, 2004-07-27 at 11:33, Jason Fischl wrote:
> > > -----Original Message-----
> > > From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
> > > [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf Of
> > > Robert Sparks
> > > Sent: Tuesday, July 27, 2004 7:02 AM
> > > To: 'resiprocate-devel@xxxxxxxxxxxxxxxxxxx' Resiprocate
> > > Subject: [reSIProcate] DUM API question
> > >
> > >
> > > Derek asked me a question that I don't remember the answer to.
> > >
> > > Consider the case where we issue an initial INVITE through
> > > DUM. The request goes through one proxy and forks to two
> > > endpoints. The first endpoint returns a 183. Sometime later,
> > > the second endpoint returns a 603.
> > >
> > > What is the flow through DUM when this 603 comes in? We've
> > > got an existing dialog (with a usage/ early dialog state).
> > > Should we create a second dialog with a usage for the 603?
> > > (Dialog feels right, but usage doesn't.) How does the
> > > usage with the 183 on it get told that it needs to come to
> > > an end?
> > >
> > > Variants of this to think through before answering are:
> > > 1) More than one branch returning provisionals that
> > >    set up early dialogs.
> > > 2) Additional signaling activity on one of those
> > >    branches (consider the original scenario but toss
> > >    an UPDATE into the mix).
> > >
> >
> > It seems to me that when any 6xx response is received by dum, it should
> > notify each usage that was created from the corresponding request  that
> it
> > has been terminated.
> 
> Do we have the plumbing for this notification already? If not, where
> should it be?
> 

This should be in or called from DialogSet::dispatch, and a check should be
added to match the failure response to mCreator->getLastRequest(). I've got
a temporary(fairly meaningless, okay just plain wrong) hack where the real
logic should go. See "//!dcm! -- even if this matches" in DialogSet.cxx.

> >  As for what does the 6xx create: it will create a
> > temporary ClientInviteSession(Usage) that will be deleted as soon as the
> > handler returns.
> >

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.

> > The DUM Dialog is purely implementation and the Application does not
> have
> > access to it. We do this for all failure responses. The terminology is
> not
> > quite right but it is pretty convenient for the programmer.
> >
> >
> 
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel