[VoiceOps] Billing of Forwarded Calls

[Alex Balashov]

Then you're screwed.  This is why I mandate the use of CPE that supports 
authentication and/or registration;  if it can't be authenticated, it 
can't be authorised or accounted either.  AAA for the win.

Scott Berkman wrote:

> A is not possible since the ANI being sent is “valid” in NANP.  B is not 
> possible based on customer demands, otherwise this would be my preferred 
> solution.  C is not supported by some of the systems involved.
> 
>  
> 
>                 -Scott
> 
>  
> 
> *From:* anorexicpoodle [mailto:anorexicpoodle at gmail.com]
> *Sent:* Wednesday, November 11, 2009 3:47 PM
> *To:* Scott Berkman
> *Cc:* 'Alex Balashov'; voiceops at voiceops.org
> *Subject:* RE: [VoiceOps] Billing of Forwarded Calls
> 
>  
> 
> If this is in the context of a customer trunk, and the forward is being 
> completed via invite from their system, and I presume that means that 
> they will stay in the flow for the duration, then you can either:
> 
> A: Assign their trunk a default source ani for all traffic that doesn't 
> have a valid source (from, diversion etc) assigned to the trunk.
> 
> B: Reject the call since it was offered from an ANI that is not 
> provisioned on the customers trunk.
> 
> C: Challenge all invites and assign the call to the authenticating account
> 
> Unfortunately if the CPE can't/won't tell you the actual originating 
> number and the 2 calls are not explicitly related (forwarded by B2BUA so 
> callid is different etc) then you don't have much other recourse.
> 
> 
> 
> On Wed, 2009-11-11 at 15:23 -0500, Scott Berkman wrote:
> 
>  
> 
> Think about this in the context of a SIP trunking provider where the systems in question are customer systems that you cannot control, pull CDR off of, or require diversion headers from.  You can't tell the customer you won't provide them SIP trunks because "their system sucks".  Because you are trying to support a wide range of systems, the presence or absence of a diversion header will be a variable.
> 
>  
> 
>         -Scott
> 
>  
> 
> -----Original Message-----
> 
> From: anorexicpoodle [mailto:anorexicpoodle at gmail.com] 
> 
> Sent: Wednesday, November 11, 2009 3:12 PM
> 
> To: Alex Balashov
> 
> Cc: Scott Berkman; voiceops at voiceops.org <mailto:voiceops at voiceops.org>
> 
> Subject: Re: [VoiceOps] Billing of Forwarded Calls
> 
>  
> 
> Look for the presence of a diversion header, if the diversion header is
> 
> there, then that is the responsible party. I cannot speak to the
> 
> particulars of your platform, but as long as you make sure that if a
> 
> diversion header is present it is assigned as the responsible party your
> 
> billing should come out correct in this flow. If your switch/endpoint is
> 
> not adding a diversion header then I am inclined to agree with Alex.
> 
>  
> 
> On Wed, 2009-11-11 at 13:01 -0500, Alex Balashov wrote:
> 
>> Scott Berkman wrote:
> 
>> 
> 
>> > So how do most of you deal with billing of forwarded calls (specifically 
> 
>> > where the calling number on the forwarded leg is using the original 
> 
>> > calling number from the inbound leg) in a SIP environment when the 
> 
>> > originally called number is not preserved in the new invite?  In this 
> 
>> > case there is no way to match the calling or called number to a specific 
> 
>> > customer.
> 
>> > 
> 
>> > Do you bill by IP address or interface instead?  Do you somehow use a 
> 
>> > system that correlates the forwarded leg to the original inbound leg?  
> 
>> > I’ve come across this issue a few different times when trying to bill 
> 
>> > off of SIP messaging logs, for instance radius off a SIP SBC or SQL logs 
> 
>> > from SER.
> 
>> 
> 
>> In my view, that depends on what is doing the forwarding.
> 
>> 
> 
>> If it's the customer handset actually initiating the forward, then it 
> 
>> should just look like a normal termination call from the customer.
> 
>> 
> 
>> If it's a multi-tenant switch or other call control agent, it should 
> 
>> have some way of associating forwarded calls with an account and 
> 
>> sticking an account ID or similar into the CDRs, which will reveal who 
> 
>> to bill and presumably the rate plan to use.
> 
>> 
> 
>> If it can't do that, the product sucks.
> 
>> 
> 
>> -- Alex
> 
>> 
> 
>  
> 
>  
> 
>  
> 
>  
> 


-- 
Alex Balashov - Principal
Evariste Systems
Web     : http://www.evaristesys.com/
Tel     : (+1) (678) 954-0670
Direct  : (+1) (678) 954-0671