< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

RE: [reSIProcate] DUM API question


> -----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. 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.