Re: [reSIProcate] DUM v. 2 proposal (early draft; server)
Responses inline...
Quoting Jay Hogg <jay@xxxxxxxxxxxxxx>:
> I like getting rid of the factory stuff and I think I like what you are
> proposing
> on the changes. I have 1 "big" question so far:
>
> How do these changes play when an INVITE is sent and you are waiting for
> a response?
>
> My background is 20yrs of traditional telephone and the concept of
> "making a call" but
> not having a controlling point until the other end responds took a lot
> of getting used
> to (I do fully understand why).
>
> The factory methods work well in this scenario - will the virtual call
> back have
> visibility to the AppDialogSet to be able to handle association back to and
> originating request?
Good question. I'm still tinkering, but here is what I'm thinking. Client
invites are created by the app, handed to the DUM with manage and are
immediately accessible to the app as a DUMPtr. In fact, nothing happens until
the app asks for and sends the INVITE. So the app has a control point before any
response arrives.
When a response arrives, the initially created client invite gets a call back
indicating the response. This callback is distinct from but similar to callbacks
on additional forks.
I think the bit that I have not communicated well is that the initially created
client invite functions as the AppDialogSet. The class AppDialogSet is subsumed
by the base class of the application client invite. Each forked response will
trigger a callback on the application client invite allowing the application to
create and manage a new application session instance (maybe the same type as the
original, maybe different -- up to the application). This new instance is
accessible from the original client invite instance in its role as what used to
be AppDialogSet.
>
> Today I use a derived AppDialogSet to contain the mapping between the
> dialog callback
> Client::onNewSession and the requestor - will AppDialogSet(derived) be
> via a virtual
> method also? Passed on a send() for a client INVITE? Subject to
> auto_ptr<> so it doesn't
> go away until the application side has also disposed of it?
>
> I'm thinking through this in the concept of hundreds of concurrent
> DialogSets in
> existance with possible hundreds of outstanding client invites.
Let me know if APpDialogSet requires independant existance. My current take
(from discussion with Derek) is no, but I/we may be off. It is easy enough to
have something like an invite client collection be the first instance and each
of the dialogs, including the first be a distinct derived application class. I
think I am leaning against that model because most apps won't want mutiple
sessions to arise from a single INVITE? However, there will frequently be
multiple dialogs, so I can see it both ways.
>
> I've got another email started from your first with questions/comments
> but this open
> a lot of new ones that now affect my questions ;)
I look forward to your further input; absolutely essential that real experience
inform the design!
thanks,
david
>
> Jay
>
>
>
> david Butcher wrote:
>
> >Hi all,
> >
> >(more DUM v. 2)
> >
> >My proposal for the server side is to abandon the factory idea. Instead,
> there
> >are virtual methods on DUM for each server type where the request is passed.
> The
> >server application, like the client side, creates an instance of the
> derived
> >server usage with an abitrary constructor. Again, a manage() method is used
> to
> >pass the usage to DUM and a DUMPtr is returned. This version of manage takes
> the
> >incoming message as an argument in addition to the auto_ptr'd instance and
> >optional fifo. After calling manage, the application asks the
> DUMPtr-wrapped
> >instance to accept or reject or whatever.
> >
> >There is the question of what to do if the application doesn't manage the
> >request at all.
> >
> >This same approach can be used to handle forking and in-dialog requests.
> Each
> >fork causes a virtual callback on the application client instance and the
> client
> >decides how to manage the message (e.g. 180). In this case, the manage
> method is
> >invoked on the application instance rather than the DUM but again with the
> >auto_ptr'd new instance, and the message.
> >
> >In dialog-requests are the same; the usage that set up the dialog gets the
> >callback and hosts the manage() call.
> >
> >david
> >
> >
> >_______________________________________________
> >resiprocate-devel mailing list
> >resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> >https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> >
> >
>