[Freeswitch-users] Splitting CDRs on call forward

Dave R. Kompel drk at drkngs.net
Mon May 27 23:00:01 MSD 2013


Yes, I understand that. The method I gave you works for all cases, and you don't have to have a lot of special code for each case. It's much easier to have the logic once, and that way as your application grows, and needs to be changed, it's a lot easier.  
   
--Dave
      _____  

  From: Jon Schøpzinsky [mailto:jos at firstcom.dk]
To: FreeSWITCH Users Help [mailto:freeswitch-users at lists.freeswitch.org]
Sent: Mon, 27 May 2013 11:29:10 -0700
Subject: Re: [Freeswitch-users] Splitting CDRs on call forward

Hello Dave,

The main problem isnt really the first scenario, as only the last leg needs to be billed. The biggest issue is with the second scenario, since both calls need to be billed, as theres two billing entities involved. I am also not using the FreeSWITCH directory, as the authentication and registration are handled by an upstream OpenSIPS instead.

But thank you for the very thorough description. Its definitely inspiring working towards a solution.
Right now im leaning towards using hooks, and taking care of the billing in lua, instead of using the internal CDR system. That way i can get it exactly as i want it :)

/Jon
________________________________________
Fra: freeswitch-users-bounces at lists.freeswitch.org [freeswitch-users-bounces at lists.freeswitch.org] På vegne af Dave R. Kompel [drk at drkngs.net]
Sendt: 27. maj 2013 18:58
Til: FreeSWITCH Users Help
Emne: Re: [Freeswitch-users] Splitting CDRs on call forward

This is a major can of worms. I have an comericial carrier softswitch based on FS, and what I did to be able to imlment billing the right legs to the right account was the following:

Have a flag on your gateways so you can mark them as "pstn-uplink", or whatever you want to call it. This way you know that it's the "other" leg's endpoint is the entity you want to bill.

Next, in your directory, make sure you set a variable for the user that has it's billing identity for example "myapp_user" or "myapp_account". If you use account then you can associate more then one user to the same account, if that's the way you're billing works.

Now, if you make sure all calls to users, use the user/username at domain<mailto:user/username at domain> form of the dial string, you will also have the variable set on calls terminating to that user. Now you can bill, on normal calls both incoming calls (charge for DID usage) and outbound calls.

When you get any inbound call from a gateway that's marked as "PSTN" then set a variable on that leg, when it calls a user, that indicates it's the PAID inbound leg for that user, before bridging to the "user" channel.

To implment forwarding, in your processing of a call to a user, before bridging to the "user" channel, see if the users is forwarding, if so all you have to do, in your dialplan, or external code handling the dialplan is: "set_user to the user they called", then "transfer to: ${Forwarding_number} XML ${user_context}". Because you did the "set_user" first, the call will go back to CS_ROUTING, but look like it's from the user that did the forwarding. This way, if the call is from a gateway that isn't in the right context to dial the forwarding number, it won't matter, and the B-LEG will go through your dialplan logic, like the call is made form the user, and you can set a variable on the B_LEG in the dial string to tell it who the call is on behalf of, if it goes out a gateway that is marked as "PSTN".

This way the same logic of how you tag the PSTN leg as being called from a user, is the same for a call made from the user, or forwared by the user.

Since any users in the middle that are forwarding to internal numbers, it doesn't matter how many forwarding hops you go through, the original A-LEG if PSTN will get billed to the user it called, and the final B-LEG will get biled to the user that did the forwarding, that caused the call to leave your switch.

--Dave

________________________________
From: Jon Schøpzinsky [mailto:jos at firstcom.dk]
To: FreeSWITCH Users Help [mailto:freeswitch-users at lists.freeswitch.org]
Sent: Mon, 27 May 2013 09:01:49 -0700
Subject: [Freeswitch-users] Splitting CDRs on call forward

Hi List,

I am implementing call forwarding on a multi tenant system, and therefore
need to split CDR's when the call forward happens, so that if the
receiving user also has his account call forwarded, he pays for his part
of the call.

A calls B
B forwards to C
C forwards to an external mobile phone.

B has a free call from B to C, but C needs to pay for the forwarding to
the mobile phone. Therefore i need a separate CDR for the C to Mobile
phone call.

Another example would be this

A works in Company A, and B works in Company B
They are both users on our system, and therefore is on the same freeswitch.

A calls B
B Forwards to an external mobile phone.

Here A needs to pay for the call from A to B, and B needs to pay for the
call being forwarded to his mobile phone.

Do anybody have an idea as to how to implement this in freeswitch. Back in
my Asterisk days, this would be done by the ForkCDR command.


Venlig hilsen/kind regards

Jon Leren Schøpzinsky


_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting at freeswitch.org<mailto:consulting at freeswitch.org>
http://www.freeswitchsolutions.com<http://www.freeswitchsolutions.com/>


</>

Official FreeSWITCH Sites
http://www.freeswitch.org<http://www.freeswitch.org/>
http://wiki.freeswitch.org<http://wiki.freeswitch.org/>
http://www.cluecon.com<http://www.cluecon.com/>

FreeSWITCH-users mailing list
FreeSWITCH-users at lists.freeswitch.org<mailto:FreeSWITCH-users at lists.freeswitch.org>
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org<http://www.freeswitch.org/>



--
This message has been scanned for viruses and dangerous content, and is believed to be clean.

_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting at freeswitch.org
http://www.freeswitchsolutions.com




Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users at lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
      
   
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20130527/d2a6e27a/attachment.html 


Join us at ClueCon 2011 Aug 9-11, 2011
More information about the FreeSWITCH-users mailing list