Re: [reSIProcate] dum - sip stack many-to-one relation question
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
> > >
> >
>
>