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?
> As for what does the 6xx create: it will create a
> temporary ClientInviteSession(Usage) that will be deleted as soon as the
> handler returns.
>
> 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.
>
>