Re: [reSIProcate] hunt group using b2bua
On 22/08/12 16:22, Douglas Hubler wrote:
> Some members of my team are giving me an indication that the b2bua
> portion of resiprocate is not in active development. Specifically we
I confess to contributing that code, and I can confirm your observation
is correct
Most of it hasn't been touched for over 5 years, it is not consistent
with the code quality in the rest of the stack nor is it an outstanding
example of my own work.
> were looking at it to build a hunt group feature. Currently we've
> implemented hunt groups w/o a b2bua using sipXecs SIP tack but once
> the number of members hit's a 5 or 6 the amount of SIP traffic that is
> generate back to the caller is too much. I don't think this is
> limitation of the sipXecs SIP stack so much as it's a limitation of
> SIP in this area. I'm not a SIP expert but I can gather more details
> if nec. Our idea was that implementing this as a B2BUA would relieve
> the work from the client and allow the feature to scale.
>
> So my questions to group are:
> 1. can large hunt groups be implemented w/o B2BUA
You would need to define hunt group and large in more specific detail.
Generally, a B2BUA may be able to do things that a proxy can't do, like
answering the A-leg of a call and keeping the caller occupied with hold
music while doing the hunt exercise. A proxy is not able to answer any
call itself.
> 2. is this a fair assessment of b2bua module in resip?
Yes (see comment above)
> 3. folks that use resip use something else when they need b2bua?
I have a few variations of the b2bua code, not all based on the libb2bua
code that is in the open source distribution of resip.
Some things, like media relay (without any other b2bua logic) can be
done with reTurnServer
> 4. does the b2bua module just need the right project to improve it?
I would be quite happy for it to be ripped out of the stack and
completely replaced if something better comes along
However, I believe that despite the shortcomings of the existing code,
it does provide a basic starting point for something better to be developed
Scott sent me a list of some of the major shortcomings (e.g. doesn't
handle re-INVITE properly), I'm happy to share that with you.
However, it does work for the purpose it was built for, and it was
observed to handle > 20 concurrent calls for weeks at a time without
memory leaks or crashes. Of course, this may be subject to the fact
that it was always used with a specific Cisco voice gateway and
Sipura/Linksys user agents, and it may behave differently in another
environment.
> 5. Would more people use the b2bua module if it was improved? If so,
> please respond w/details on/off list so we can have confidence we
> wouldn't be owning this module alone.
I don't currently have any commitment to support it in any commercial
environment, so I can't commit to owning it long term, but happy to look
at any commercially motivated requests for collaboration and enhancement.