Hi Dan,
Thanks for the all the info! Ok, question on this part:
3. Accounting it is bit more accurate (you have the session total duration inside the accounting packets), so radius will be no longer responsible of calculating the session durations from timestaps.
To interoperate with CDRTool you still need the data in the radacct table formatted as per normal by Freeradius, right? By accouting packet are you referring to the radius accouting packets? If you say Yate puts session times in the accouting packets how does this all stick together? Does OpenSER still do the radius accouting part, or do I need to configure Yate to do it instead?
thanks a lot! Andy.
--------- Original Message -------- From: Dan-Cristian Bogos danb.lists@googlemail.com To: A.smith a.smith@ukgrid.net Cc: users@lists.openser.org Subject: Re: [OpenSER-Users] FreeRADIUS-CDRTool Prepaid Connector 1.1 Released Date: 13/02/08 12:15
Hi Andy,The original config was built with Yate in mind due to openser
incapacity (before release 1.3) of disconnecting the calls. Since 1.3.0 the dialog module should be able to timeout the calls, in theory you should no longer need extra software like Yate.
I would still recommend using Yate combined with OpenSER in the case you
are doing some sort of "Carrier business", for the following reasons:1. It creates two different legs for your call (in and out) same as Cisco does, and hides one side from the other (eg. removes the via headers and any revealing ip information inside SDP - so your partners should not know where the traffic comes from).
- You have more protocols available in.3. Accounting it is bit more
accurate (you have the session total duration inside the accounting packets), so radius will be no longer responsible of calculating the session durations from timestaps.
- Yate can work in rtp_forward mode, therefore no extra overhead given by
rtp processing.So basically what the connector does (as specified in the documentation), for each call which is authorized by radius, the connector will ask permission from cdrtool. If permission is granted, it will return in a avp to openser the maximum duration allowed for the call (timeout value) plus credit available, for the case of special uas able to display that.
By receiving accounting stop packet, the connector will inform cdrtool
about call disconnection therefore clearing the lock and debiting the balance inside cdrtool. The rtp stream has nothing to do with this scenario, so you don't need to touch your NAT support configuration, it's all in the signaling.
Let me know if you need further info.Cheers,DanBOn Feb 13, 2008 12:53 PM
________________________________________________ Message sent using UK Grid Webmail 2.7.9
CDRTool will take the data from where you tell it (inside global.inc) and it is able to work with Cisco style cdr format already, so all you need to do is to instruct yate or radius to put the cdrs where you need them. I would not insist with yate support on this channel since we are using openser mailing list for yate related questions (for more detailed info, feel free to mail me directly or use yate mailing list).
By accouting packet are you referring to the radius accouting packets? If you say Yate puts session times in the accouting packets how does this all stick together?
Yes I was speaking about radius accounting packets, although yate can also put the cdrs directly inside database. As I have told you, it is just a recommendation, I usually use openser cdrs just for my info due to missed calls and sip-sip calls which I don't pass through yate, and ask CDRTool to display them (you can configure more datasources inside cdrtool).
DanB
On Feb 13, 2008 1:30 PM, A.smith a.smith@ukgrid.net wrote:
Hi Dan,
Thanks for the all the info! Ok, question on this part:
- Accounting it is bit more accurate (you have the session total duration
inside the accounting packets), so radius will be no longer responsible of calculating the session durations from timestaps.
To interoperate with CDRTool you still need the data in the radacct table formatted as per normal by Freeradius, right? By accouting packet are you referring to the radius accouting packets? If you say Yate puts session times in the accouting packets how does this all stick together? Does OpenSER still do the radius accouting part, or do I need to configure Yate to do it instead?
thanks a lot! Andy.
--------- Original Message -------- From: Dan-Cristian Bogos danb.lists@googlemail.com To: A.smith a.smith@ukgrid.net Cc: users@lists.openser.org Subject: Re: [OpenSER-Users] FreeRADIUS-CDRTool Prepaid Connector 1.1 Released Date: 13/02/08 12:15
Hi Andy,The original config was built with Yate in mind due to openser
incapacity (before release 1.3) of disconnecting the calls. Since 1.3.0the dialog module should be able to timeout the calls, in theory you should no longer need extra software like Yate.
I would still recommend using Yate combined with OpenSER in the case you
are doing some sort of "Carrier business", for the following reasons:1. It creates two different legs for your call (in and out) same as Cisco does, and hides one side from the other (eg. removes the via headers and any revealing ip information inside SDP - so your partners should not know where the traffic comes from).
- You have more protocols available in.3. Accounting it is bit more
accurate (you have the session total duration inside the accounting packets), so radius will be no longer responsible of calculating the session durations from timestaps.
- Yate can work in rtp_forward mode, therefore no extra overhead given
by rtp processing.So basically what the connector does (as specified in the documentation), for each call which is authorized by radius, the connector will ask permission from cdrtool. If permission is granted, it will return in a avp to openser the maximum duration allowed for the call (timeout value) plus credit available, for the case of special uas able to display that.
By receiving accounting stop packet, the connector will inform cdrtool
about call disconnection therefore clearing the lock and debiting the balance inside cdrtool. The rtp stream has nothing to do with this scenario, so you don't need to touch your NAT support configuration, it's all in the signaling.
Let me know if you need further info.Cheers,DanBOn Feb 13, 2008 12:53 PM
Message sent using UK Grid Webmail 2.7.9
-
A.smith -
Dan-Cristian Bogos