[reSIProcate] dum - sip stack many-to-one relation question

Mon Nov 21 11:41:22 CST 2005

I thought about it and actually started working on that. This was an ideal
solution for me until...
I have designed an event model in which each callback generates a specific
event and pushes it to event queues. The events were holding callback
arguments (including the relevant DUM handles).

Application threads were supposed to process these events, and send DUM
commands to perform operations on the DUM handles. For instance, when
onOffer event has been processed, I intended to perform the
handle->provideAnswer() and handle->accept() within an execution of a DUM
command. I was doing so in order to prevent race conditions.

Then, I realized that at the time the command->execute occurs, the DUM
session state may not longer be relevant. Since I have no access to these
states (private), DUM might assert the command execute and I have no control
on that. Is there any solution for that ?

On 11/21/05, Jason Fischl <jason at counterpath.com> wrote:
>
> I suggest that you create an async event for each of the Dum handlers
> and pass this to your application through a message queue(Fifo). In
> this way you can have multiple threads running in the application.
>
> On 11/21/05, Meir Elberg <elbergm at gmail.com> wrote:
> > My application needs to interact with external processes using different
> > protocols than SIP. This interaction might get stuck since it is a
> network
> > request. It will stuck in the DUM callback methods. Therefore the
> functions
> > better be designed asynchronously.
> > You mentioned that most of the processing occurs either in the sip stack
> > itself (SipStack) or in the application layer above DUM.
> > But the application layer isn't separated from DUM, so actually it is
> part
> > of the DUM portion of the CPU load.
> > My goal is that the architecture of the B2B will not cause hanging of a
> > phone call because of delays in processing of a previous phone call. in
> this
> > architecture I cannot achieve this goal. What are you suggesting ?
> >
> > If Micky's suggestion is good, shouldn't the TransactionUser or the
> > MessageFilterRule be changed as mentioned before?
> >
> > Meir.
> >
> > On 11/20/05, Jason Fischl <jason at counterpath.com> wrote:
> > > Do you think that the cpu load in the dum portion of the code will be
> > > significant and would benefit by having multiple threads? You will
> > > likely find that most of the processing occurs either in the sip stack
> > > itself (SipStack) or in the application layer above dum. But in any
> > > event, you can do what you suggest. It might be less effort
> > > programmatically to just have two B2BUA processes running on the same
> > > host but drunning on different ports.
> > >
> > >
> > > Jason
> > >
> > >
> > > On 11/13/05, Meir Elberg < elbergm at gmail.com> wrote:
> > > > The motivation of doing so is not just for handling multiple users
> but
> > also
> > > > to have more than one thread that processing the calls in order to
> > improve
> > > > the B2B performance.
> > > >
> > > > The one stack requirement is needed in order to have one single
> > listening
> > > > point for the B2B.
> > > >
> > > > So, if it is possible, I still don't see how the incoming calls will
> be
> > > > load shared between the different DUMs.
> > > >
> > > > Thanks,
> > > > Elberg Meir.
> > > >
> > > >
> > > > On 11/10/05, Jason Fischl <jason at counterpath.com> wrote:
> > > > > It absolutely can. But it isn't necessary to have multiple dum
> > > > > instances (with one stack) to accomplish this. All that is needed
> is
> > > > > to add multiple UserProfiles.
> > > > >
> > > > > On 11/10/05, Micky Kaufmann < micky at proxy.co.il> wrote:
> > > > > > I still don't understand why DUM can't support multiple users in
> > > > > > multiple instances with only one stack instance. (By making
> > > > > > MessageFilterRule virtual)
> > > > > > Are there problems preventing DUM from working like that?
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: resiprocate-devel-bounces at list.sipfoundry.org
> > > > > > [mailto:
> > resiprocate-devel-bounces at list.sipfoundry.org]
> > > > On Behalf Of
> > > > > > Jason Fischl
> > > > > > Sent: Thursday, November 10, 2005 6:56 PM
> > > > > > To: Meir Elberg
> > > > > > Cc: resiprocate-devel at list.sipfoundry.org
> > > > > > Subject: Re: [reSIProcate] dum - sip stack many-to-one relation
> > question
> > > > > >
> > > > > > The stack was definitely designed to have multiple TUs. However,
> dum
> > > > > > was intended to support multiple users in a single instance.
> Running
> > > > > > multiple dum TUs would be useful if you wanted to have different
> > > > > > master profile characteristics and different handlers running
> for
> > the
> > > > > > different instances.
> > > > > >
> > > > > > Jason
> > > > > >
> > > > > >
> > > > > > On 11/10/05, Meir Elberg < elbergm at gmail.com> wrote:
> > > > > > > I also thought of this option, however the MessageFillterRule
> is
> > not
> > > > > > > abstract.
> > > > > > > My concern is whether there are additional problems with this
> > > > > > approach,
> > > > > > > since according to Scott, it was not designed that way.
> > > > > > >
> > > > > > >
> > > > > > > On 11/9/05, Jason Fischl < jason at counterpath.com> wrote:
> > > > > > > > Yes. You can attach multiple DialogUsageManagers to a single
> > stack
> > > > > > by
> > > > > > > > using the message filter rules as Micky suggests. There is
> an
> > > > > > example
> > > > > > > > of this in repro although repro is not a second instance of
> dum
> > it
> > > > > > > > does demonstrate the idea of having two TUs.
> > > > > > > >
> > > > > > > > On 11/9/05, Micky Kaufmann < micky at proxy.co.il> wrote:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > DUM is a TransactionUser which means it has
> > > > > > 'setMessageFilterRuleList'
> > > > > > > in
> > > > > > > > > it.
> > > > > > > > >
> > > > > > > > > Wasn't the stack designed to forward messages to more than
> one
> > > > > > > > > TransactionUser?
> > > > > > > > >
> > > > > > > > > If it was designed that way is there still a reason for
> not
> > > > > > overriding
> > > > > > > > > 'setMessageFilterRuleList' to a few dum threads and still
> work
> > > > > > with one
> > > > > > > > > stack?
> > > > > > > > >
> > > > > > > > > If both answer are optimistic why not have a HashTable of
> > > > > > DumThreads and
> > > > > > > > > update MessageFilterRule to filter messages according to
> > > > > > > > > transactionId/DialogId hash value?
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > ________________________________
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > From:
> > > > resiprocate-devel-bounces at list.sipfoundry.org
> > > > > > > > > [mailto:
> > > > resiprocate-devel-bounces at list.sipfoundry.org ]
> > > > > > > On
> > > > > > > > > Behalf Of Scott Godin
> > > > > > > > > Sent: Wednesday, November 09, 2005 4:34 PM
> > > > > > > > > To: Meir Elberg;
> > > > resiprocate-devel at list.sipfoundry.org
> > > > > > > > > Subject: RE: [reSIProcate] dum - sip stack many-to-one
> > relation
> > > > > > > question
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > You cannot attach many DUM objects to the same stack - it
> was
> > not
> > > > > > > designed
> > > > > > > > > this way.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > ________________________________
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > From:
> > > > resiprocate-devel-bounces at list.sipfoundry.org
> > > > > > > > >
> > > > [mailto: resiprocate-devel-bounces at list.sipfoundry.org
> > ]
> > > > > > > On
> > > > > > > > > Behalf Of Meir Elberg
> > > > > > > > > Sent: Wednesday, November 09, 2005 4:09 AM
> > > > > > > > > To: resiprocate-devel at list.sipfoundry.org
> > > > > > > > > Subject: [reSIProcate] dum - sip stack many-to-one
> relation
> > > > > > question
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > I'm checking the option to attach many dum objects to one
> SIP
> > > > > > stack.
> > > > > > > > > Therefore, my first question is whether it is possible and
> if
> > so,
> > > > > > is it
> > > > > > > > > recommended ?
> > > > > > > > >
> > > > > > > > > The reason for doing so is that I wish to have one
> listening
> > > > > > point,
> > > > > > > i.e. by
> > > > > > > > > adding one transport to a SIP stack and have many dum
> stacks
> > > > > > (working as
> > > > > > > > > UAS) using this sip stack, working in different threads in
> > > > > > parallel.
> > > > > > > > >
> > > > > > > > > Another question is when a SIP request is received to the
> SIP
> > > > > > stack,
> > > > > > > what
> > > > > > > > > is the policy of distribution of this SIP request between
> the
> > > > > > different
> > > > > > > dum
> > > > > > > > > objects attached to the SIP stack ?
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > Elberg Meir
> > > > > > > > > Ventego Networks
> > > > > > > > >
> > _______________________________________________
> > > > > > > > > resiprocate-devel mailing list
> > > > > > > > > resiprocate-devel at list.sipfoundry.org
> > > > > > > > >
> > > > > > >
> > > >
> > https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > resiprocate-devel mailing list
> > > > > > > resiprocate-devel at list.sipfoundry.org
> > > > > > >
> > > >
> > https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > resiprocate-devel mailing list
> > > > > > resiprocate-devel at list.sipfoundry.org
> > > > > >
> > > >
> > https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> > > > > >
> > > > >
> > > >
> > > >
> > >
> >
> >
> > _______________________________________________
> > resiprocate-devel mailing list
> > resiprocate-devel at list.sipfoundry.org
> > https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20051121/ce5221d9/attachment.htm>