RE: [reSIProcate] Basic DUM Questions
Hi J,
> -----Original Message-----
> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf Of JDM
> Sent: Wednesday, July 07, 2004 3:59 PM
> To: resiprocate-devel
> Subject: [reSIProcate] Basic DUM Questions
>
>
> I've been trying to build a B2BUA using the the new DUM and I'm
> doing more head banging than coding so I thought I would turn to
> the experts.
>
> Part of my problem is certainly a lack of understanding of the
> architectural assumptions in the DUM/stack. For example:
>
> - Should I use one stack or two in a B2BUA?
If you are using DUM, you probably should use one stack. There currently
isn't a mechanism for using dum with more than one stack although some
discussion occurred about how to do this at the last work session.
> - Do I need multiple DUMs or is one preferred?
My guess is that you should be able to do everything with one DUM.
> - Should I create a single fdset or do I need a unique one per stack?
You can use a single fdset, but if you only have one DUM, then it should be
easy. Do you expect to have any other file descriptors that you will be
selecting on other than those managed by resip?
> - etc.
>
> I've tried multiple approaches and I get various degrees of
> success but I would feel much better understanding the reasons
> behind the choices. Is there any documentation out there or could
> anyone provide guidance on a reasonable way to use the DUM in
> buiding a B2BUA that must support multiple connections between
> incoming callers and media server resources?
>
At this point, there isn't too much documentation on how to use dum. dum's
interface is still changing a bit as people use it. It should stabilize
sometime in the next month or two but for now be prepared for some changing
interfaces. The underlying transaction layer of resiprocate is very stable
and you could always decide to build your b2bua based on it. There is at
least one company that has a commercial b2bua based on this layer. Of
course, this requires you to do a lot more stuff in the application. Even in
this case, you would probably just have one stack.
We have some cases at PurpleComm where we use multiple instances of a resip
SipStack in the same process. For example, we can run a proxy and a presence
server in the same process but as different threads. In this case, the
stacks really don't have anything in common with each other so it doesn't
make sense to share a stack object.
Even in the case of a b2bua where you have one side of the b2bua listening
on eth0 and the other side listening on eth1, you can still implement this
using different transports within a single stack and it will be easier to
manage the application that way.
Hope that helped.
Jason