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 <jp...@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" <o...@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 <jp...@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@lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >> >>_______________________________________________ >>Users mailing list >>Users@lists.opensips.org >>http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > _______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users