[OpenSER-Users] FreeRADIUS-CDRTool Prepaid Connector 1.1 Released

[Andy Smith]

Hi Dan,

  one other query on the below, regarding Yate providing more accuarate accounting, if OpenSER is used with mediaproxy will this not provide the same level of accuracy (as Mediaproxy actually sits in the RTP stream)?

        thanks Andy.
  ----- Original Message ----- 
  From: Dan-Cristian Bogos 
  To: A.smith 
  Cc: users at lists.openser.org 
  Sent: Wednesday, February 13, 2008 1:07 PM
  Subject: Re: [OpenSER-Users] FreeRADIUS-CDRTool Prepaid Connector 1.1 Released


  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). 
  2. 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.
  4. 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,
  DanB






  On Feb 13, 2008 12:53 PM, A.smith <a.smith at ukgrid.net> wrote:

    Hi Dan/List,

     I was reading the post below and trying to understand how your config
    works. If
    you are implementing this with something like a Cisco PSTN then you need all
    of
    these: PSTN, OpenSER, Mediaproxy and Yate involved in the SIP route? Does
    the RTP
    stream have to route via Yate and mediaproxy? :S

    thanks for any help! cheers Andy.

    >Hey Marc,
    >
    >I use Yate for doing that. It is simple and works out of the box (with
    adding few
    >lines in configs of course).
    >
    >I take Session timeout returned from connector and pass it to yate in a sip
    header
    >Process that header in regex routing and define the value as timeout for
    session.
    >Yate knows by default that when a session has a parameter "timeout"
    returned
    >from routing to disconnect the call when timeout is hit.
    >
    >Let me know if you need further info, so I can send you some config files
    if you
    >want to. You can contact me on IRC for live support (DanB).
    >
    >
    >All the best,
    >DanB

    ________________________________________________
    Message sent using UK Grid Webmail 2.7.9



    _______________________________________________
    Users mailing list
    Users at lists.openser.org
    http://lists.openser.org/cgi-bin/mailman/listinfo/users





------------------------------------------------------------------------------


  No virus found in this incoming message.
  Checked by AVG Free Edition. 
  Version: 7.5.516 / Virus Database: 269.20.2/1271 - Release Date: 11/02/2008 08:16
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20080213/ee37e52c/attachment.htm>