[Spce-user] Transit Carrier/Provider Billing

[Jon Bonilla (Manwe)]

El Mon, 15 Apr 2013 14:31:41 +0100
Deon Vermeulen <vermeulen.deon at gmail.com> escribió:

> Hi,
> 
> Is it possible to do Carrier Transit Billing with SPCE?
> 
> We currently we have 3 local Peers and 2 International Peers.
> The International Peers want to route to the 3 local connected peers.
> 
> We have to Bill these International Peers for calls traversing our network.
> 

Hi Deon

I have talked to you in private but for the history of the mailing list I'll
put an answer here:

That's what we call the "transit switch scenario". You have your class5
scenario with your end users but you also want to provide pstn access to other
operators.

The ngcp system can do this but it lacks of the feature you ask: The provider
does not have the capability to bill/rate peers. It can only bill/rate
subscribers.

There's a workaround for this: If I have operator A and B which are the ones I
want to charge and give them and operators C and D are "real peers" which
provide me pstn access and I won't charge them then I create operators A and B
as subscribers instead of peers.

If you have deployed a spce system, imagine this:

- I create the subscriber "operator_A at mydomain.com"
- I asign that operator's E164 blocks as E164 numbers and aliases. (Each E164
  number you asign to a subscriber is a block actually). Even if I need to
  asign thousands of block
- I allow that operator to send any callerid by allowing all in the
  allowed_clis preference of the subscriber
- I create a fake registration so that operator won't register against the spce
  but the spce will send the calls to that operator's ip address
- I use the trusted_source preference so that operator doesn't need to
  authenticate the calls if the source is that ip address.

That way, what you have created is a subscriber with thousands of number
blocks, no register, no authentication... which is what you would need to route
calls from/to operator. What you get creating this operator as subscriber
instead of peer is:

- Calls made from this operator to another subscriber or peer can be rated.
  This is why we do it like this.
- You have more preferences in a subscriber like ncos, call_barring which are
  not present at peer level
- The operator can only have 1 ip address as we will use fake_register and
  point to one address
- You don't make use of the transit_switch scenario as no peer-to_peer calls
  are made. This is still the class5 scenario.


For operators C and D which are your carriers, the ones you wouldn't charge,
create them as peers as usual.

I don't know if at some point we'll develop peer accounting but this way is
working fine for us so there is no hurry. The difference between a subscriber
and a peer nowadays is "Do you want to charge him"?



cheers,

Jon

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20130419/c2aa2f85/attachment-0001.asc>