Rating by 'Origin - Destination' policy

[Pablo]

Hi all!

I'm trying to build the CGRateS's rating configuration with a 'Origin - Destination' rating policy. In my Destinations.csv, each prefix could have several IDs: one for the country and the rest of IDs for the zones the country belongs to.

I've several doubts with this configuration:

Q1. Where can I specify the origin prefix? Should I use the Subject field for that?

Q2. If I've to specify the origin prefix in the Subject field, I prefer to use the zone better than the prefix (I prefer to manage zones instead of country prefixes because the RatingProfile configuration will be more simple and less redundant).

So, for that, I've to use Attributes, right? To transform the Subject, from the prefix country to the Destination ID of the zone the country belongs to. How can I achieve this if a prefix could have several IDs? Could this configuration affects the performance of CGRateS?

I'll be grateful if you could give me some recommendations to configure this scenario.

Thanks!

Pablo

[Dan Christian Bogos]

Hi Pablo,

Please see inline ...

On Wed, 2019-09-25 at 09:37 -0700, Pablo wrote:
> Hi all!
>
> I'm trying to build the CGRateS's rating configuration with a 'Origin
> - Destination' rating policy. In my Destinations.csv, each prefix
> could have several IDs: one for the country and the rest of IDs for
> the zones the country belongs to.

I hope your logic is right, we treat each prefix individually, ie we
don't have the concept of country vs in-country prefixes. We always
match longest prefix we find configured for your rating plan (attached
to your rating subject). There it can be only one prefix per request.

>
> I've several doubts with this configuration:
>
> Q1. Where can I specify the origin prefix? Should I use the Subject
> field for that?

Yes, you can specify it as rating subject and enable it here:
https://github.com/cgrates/cgrates/blob/master/config/config_defaults.go#L170
The only difference it will make is that we will do multiple queries
(instead of just one) when trying to match your subject in
RatingProfiles

> Q2. If I've to specify the origin prefix in the Subject field, I
> prefer to use the zone better than the prefix (I prefer to manage
> zones instead of country prefixes because the RatingProfile
> configuration will be more simple and less redundant).

Again, we don't have the concept of zones. You will put the caller
identification /CLI in Subject field of your request and we match it
via prefixes within RatingProfiles, that is more or less all. It does
not interact with Destinations or any other part.

> So, for that, I've to use Attributes, right? To transform the
> Subject, from the prefix country to the Destination ID of the zone
> the country belongs to. How can I achieve this if a prefix could have
> several IDs? Could this configuration affects the performance of
> CGRateS?

You can use AttributeS to change the rating prefix, that is correct.
About how to organize them, the simplest way possible ;). AttributeS
does just an aliasing and it does not consider zones, so you will have
to duplicate your data in multiple Attribute profiles I guess.
Regarding performance, I don't see it that of an issue (we have tested
with about 30 mil. attribute profiles and we were having response in
real-time). The only headache is to manage data since that might be
slower.

Hope it helps.

DanB

>
> I'll be grateful if you could give me some recommendations to
> configure this scenario.
>
> Thanks!
> Pablo
>

> --
> You received this message because you are subscribed to the Google
> Groups "CGRateS" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to cgrates+u...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/cgrates/f6b9943a-a4d2-45f4-b561-7ac115198803%40googlegroups.com
> .

[Pablo]

Thank you, Dan.

I'm trying to understand the logic behing enabling 'rp_subject_prefix_matching', please, correct me if I wrong...

First of all, to implement the 'Origin - Destination' policy with 'rp_subject_prefix_matching', the subject field of the request will contain the origin caller identification, right? So if I enable 'rp_subject_prefix_matching', CGRateS will try to match the origin caller identification with the longest prefix it find configured in my rating profiles (looking in the Subject field of the rating profiles).

Summing up, in my Rating Profiles, the Subject field will contain only prefixes.

That's it?

> send an email to cgr...@googlegroups.com.

[Dan Christian Bogos]

Hi Pablo,

Please see inline ...

On Fri, 2019-09-27 at 03:28 -0700, Pablo wrote:
> Thank you, Dan.
>
> I'm trying to understand the logic behing enabling
> 'rp_subject_prefix_matching', please, correct me if I wrong...
>
> First of all, to implement the 'Origin - Destination' policy with
> 'rp_subject_prefix_matching', the subject field of the request will
> contain the origin caller identification, right?

That is correct.

> So if I enable 'rp_subject_prefix_matching', CGRateS will try to
> match the origin caller identification with the longest prefix it
> find configured in my rating profiles (looking in the Subject field
> of the rating profiles).

Correct.

>
> Summing up, in my Rating Profiles, the Subject field will contain
> only prefixes.

Yes.
>
> That's it?

The alternative is to use AttributeS with prefix matching and replacing
the subject with the pricing one you want for your CLI. In that case
you don't enable in RatingProfiles prefix matching which might be a bit
faster since you can index the filters for AttributeS.

DanB

[Pablo]

Thank you, Dan!! All clear!

Your alternative is what I'm thinking to implement. I'll disable 'rp_subject_prefix_matching', do the matching from prefixes to zones and replace the Subject with the correct zone in AttributteS.

This way I'll simplify the RatingProfile file :)

Thank you again!