RE: [reSIProcate] process incoming calls design question - UML seq diagram attached
Quoting Justin Matthews <justin.matthews@xxxxxxx>:
> Thanks David. Any answer to my question :-)?
Ok, I was kind of dodging :-)
Anyone who can explain this better than I can, please jump on in...
The current DUM model is that your application is supposed to use the Handles
to access DUM state corresponding to your application state. There has been
some effort to reduce replication of state. Notice that every callback to your
derived handler is passed a Handle.
You can get to dialog and dialogset ids from appropriate Handles (those
corresponding to DialogUsages). More relevant, you can get to an application
state object from DialogUsages with getAppDialogSet. Judicious casting will get
you to an application type that you associated with the usage at construction.
This is admittedly clumsy. There is momentum building to take another crack at
the DUM interface to fold together the application handler, the handle, and
what is currently the AppDialogSet (the application client data base).
However, I do not want to disourage your current efforts -- most of DUMs goals
will be met with the current interface; that is encapsulating the icky details
of the protocol. Nevertheless, it is worth talking about improvements to the
interface between the application and DUM that will 1. make state
correspondences clearer 2. maintain low replication of state 3. minimize
application use of casts. It is hoped that the migration of existing projects
will be relatively painless and result in clearer code all around.
There will likely be a design/coding meeting for "DUM v2" in the very near
future.
As you are a user of the current interface, I am very interested in your
perspective on improving the DUM/application interface.
david
>
> On the documentation, I would like to propose adding a separate section of
> the Wiki where I could post information and documents (or links) similar to
> the UML I sent to this group list. This section could be thought of as an
> ongoing case study with IVR Technologies initial deployment of resiprocate
> within our product. Initially I would post our experience with checking
> out, building and integrating the stack. Currently we are working on
> understanding the call flows and how to use DUM, similar to what I sent
> earlier.
>
> Thanks,
>
> -Justin
>
> -----Original Message-----
> From: david Butcher [mailto:david@xxxxxxxxxxxxxx]
> Sent: Saturday, January 22, 2005 1:10 PM
> To: Justin Matthews
> Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [reSIProcate] process incoming calls design question - UML seq
> diagram attached
>
> Hi Justin,
>
> There is some documentation for the stack proper, but little documentation
> for
> DUM.
>
> Your contributions would be/are greatly appreciated, and will inspire
> others!
>
> We are hosting a wiki at
> http://warsaw.sjc.purplecomm.com/wiki/
>
> As you will see, there is an outline there but not yet much content.
>
> A link from SipFoundry.org/reSIProcate would be helpful; who can do this --
> Alan?
>
> thanks,
> david
>
> Quoting Justin Matthews <justin.matthews@xxxxxxx>:
>
> > Hello,
> >
> > I have a question on how to use the dum. After handling the callbacks
> with
> > my InviteSessionHandler derived class, I would like to store a minimal
> > amount of information so that I can get the appropriate InviteSession for
> a
> > call at a later time. For example, when onNewSession is called I need to
> > asynchronously pass the information about the new call to my apps internal
> > system which will eventually call InviteSession::provisional and then
> > InviteSession::send. How would my internal system get the appropriate
> > InviteSession? What is the best way to do this? Simply store the
> > ServerInviteSessionHandle passed into my InviteSessionHandler? Ideally I
> > would not like to keep track of dum data objects such as the handle. Is
> > there a way to get a reference to the correct InviteSessionHandle using
> > parts of the message (callid, to, from)?
[snip other topics]