[OpenSIPS-Users] B2B top-hiding + accounting

Ovidiu Sas osas at voipembedded.com
Sat Dec 4 01:09:46 CET 2010


Try to play with manual syslog accounting.  If that works ok for you,
then I'm pretty sure that radius accounting can be adjusted to work.
I don't remember exactly if manual radius acc sent proper accounting
types (e.g. START, STOP, FAILED).  It has been a long time since I
setup a server with manual radius acc.

There are some issues with logging fake replies in b2b reply route
(like timeouts) and I think final replies to INVITE.  Those will need
to be ironed out.
Please test it out and report any issues.


Regards,
Ovidiu Sas

On Fri, Dec 3, 2010 at 3:57 PM, Jeff Pyle <jpyle at fidelityvoice.com> wrote:
> Ovidiu,
>
> I understand the separate server idea.  That indeed would be the simplest
> with the existing configuration.
>
> The manual accounting option does pique my curiosity.  I see the the
> accounting functions you referenced in the documentation.  In the
> flag-based accounting I'm used to, the radius server receives start, stop
> and failed messages from Opensips and accounts them appropriately.  Would
> I be able to look for an INVITE, BYE, etc in the routes you indicate and
> then somehow send the same messages to the radius server?
>
>
> - Jeff
>
>
> On 12/3/10 11:00 AM, "Ovidiu Sas" <osas at voipembedded.com> wrote:
>
>>Hello Jeff,
>>
>>The flag based accounting works only for relayed transactions.
>>With b2b, none of the transactions are relayed and therefor flag based
>>accounting will not work.
>>
>>If you use the local_route and b2b_request/reply routes, you can
>>invoke some manual accounting:
>>http://www.opensips.org/html/docs/modules/1.6.x/acc.html#id294003
>>Later on, you will need to aggregate the acc records for both sides of
>>the call.
>>
>>A simple solution for your existing setup would be to keep your
>>existing config as is and add an outbound server configured in b2b
>>mode.  The outbound server will do topology hiding while the existing
>>proxy server will give you accounting.
>>
>>
>>Regards,
>>Ovidiu Sas
>>
>>On Fri, Dec 3, 2010 at 10:48 AM, Jeff Pyle <jpyle at fidelityvoice.com>
>>wrote:
>>> Hello,
>>> I am having trouble understanding exactly how the top-hiding scenario
>>>does a
>>> call compared to one that simply uses the tm module to relay it.
>>>Because of
>>> this lack of understanding I can't even begin to understand the impact
>>>it
>>> would have on accounting.
>>> I'm okay with tm-based configurations that relay calls from one side to
>>>the
>>> other.  I have accounting configured to save a radius record in a mysql
>>>DB,
>>> and it works quite well.  My goal is to augment my existing
>>>configuration in
>>> such a way to accomplish exactly what the scenario name would suggest ­
>>>to
>>> hide the topology in the SIP headers.  I'd like to mimic as much of my
>>> existing configuration as possible, yet invoke the scenario in such a
>>>way to
>>> accomplish the top-hiding part.
>>> I've looked at the B2B examples, and while I can follow them for the
>>>most
>>> part, the big picture isn't clicking on how it all works.  Perhaps
>>>someone
>>> has some hints to point me in the right direction?
>>>
>>> - Jeff
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>
>>_______________________________________________
>>Users mailing list
>>Users at lists.opensips.org
>>http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>



More information about the Users mailing list