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