Re: [reSIProcate] dum - sip stack many-to-one relation question
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@xxxxxxxxx> 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@xxxxxxxxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
> > > > > [mailto:
> resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx]
> > > On Behalf Of
> > > > > Jason Fischl
> > > > > Sent: Thursday, November 10, 2005 6:56 PM
> > > > > To: Meir Elberg
> > > > > Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > > > > 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@xxxxxxxxx> 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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
> > > > > > > > [mailto:
> > > resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx ]
> > > > > > On
> > > > > > > > Behalf Of Scott Godin
> > > > > > > > Sent: Wednesday, November 09, 2005 4:34 PM
> > > > > > > > To: Meir Elberg;
> > > resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > > > > > > > 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@xxxxxxxxxxxxxxxxxxx
> > > > > > > >
> > > [mailto: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
> ]
> > > > > > On
> > > > > > > > Behalf Of Meir Elberg
> > > > > > > > Sent: Wednesday, November 09, 2005 4:09 AM
> > > > > > > > To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > > > > > > > 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@xxxxxxxxxxxxxxxxxxx
> > > > > > > >
> > > > > >
> > >
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > resiprocate-devel mailing list
> > > > > > resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > > > > >
> > >
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> > > > > >
> > > > > >
> > > > >
> > > > > _______________________________________________
> > > > > resiprocate-devel mailing list
> > > > > resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > > > >
> > >
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> > > > >
> > > >
> > >
> > >
> >
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>
>