different rates for same destination based upon INTRA or INTER call

[Aqs Younas]

Greeting list, 

I have a USA dialer check and they gave prices based upon intra and inter state call against a prefix. So, basically two prices are attached to same destination based upon calling party number. 

For example considering below deck, if calling number is 4048002020 and it  dials 2010074578 we need to choose 0.01164 and similarly if calling party is 2010072020 and it dials 2010074578 we need to choose 0.00839

NPANXX

InterstateRate

IntrastateRate

201007

0.01164

0.00839

So, I am looking for a best way to program it in cgrates. Right now i can only see using different subjects 'INTRA' and 'INTER' in rating profiles gets me what I want. 

But since i am using Suppliers for least_cost routing and subject does would not work there. So, may be i need to choose filters?

Like send from opensips an extra variable for call type(INTRA/INTER) and capturing it inside of cgrates Filter subsytem. 

So, i got a couple of questions. 

1. Will above setup work for me?
   
2. Can i send extra event variable from opensips to cgrates?
3. if filter can work how should it look like?

Sorry for too many questions. Really appreciate your help as always. 

Br, Aqs. 

[Dan B]

Hi Aqs,

you should use AttributeS for that.

You can find detailed information about full solution concerning LCR with LRN support in this year talk I had at ClueCon (should be on youtube).

Here is a link for sample TP:

https://github.com/cgrates/cgrates/tree/master/data/tariffplans/cluelrn

DanB

--
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 post to this group, send email to cgr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cgrates/07885c90-6d55-4b1c-9cee-9190122ddb43%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Aqs Younas]

Thanks DanB, That is impressive. (Y)

But somehow i am a little bit confused in understanding some Attributes filters. Like in below Attributes file(Taken from cluelrn demo). 

#Tenant,ID,Contexts,FilterIDs,ActivationInterval,FieldName,Initial,Substitute,Append,Blocker,Weight

cgrates.org,LRN_Dst3125650565,lrn,*string:Destination:3125650565,,Destination,*any,13128543000,true,false,10

cgrates.org,LRN_Dst3125650565,,,,OriginalDestination,*any,3125650565,true,false,10

cgrates.org,LRN_LATA_Dst13128543000,lrn,*string:Destination:13128543000;*rsr::OriginalDestination(!^$),,DestinationLATA,*any,358,true,false,20

 I know. 

First line is checking if destination number is  3125650565 then replace it with 13128543000. 

Second line, Since destination number has become 13128543000 due to first line effect, lets add an attribute -> OriginalDestination of value 3125650565. 

But third line is kinda becoming abstruse to me. Could you please explain this last line to me especially the last part *rsr. 

Br, Aqs

[DanB]

Hi Aqs,

Please see inline ...

On Thu, 2018-09-06 at 07:43 -0700, Aqs Younas wrote:
> Thanks DanB, That is impressive. (Y)

Thanks!

>
> But somehow i am a little bit confused in understanding some
> Attributes filters. Like in below Attributes file(Taken from cluelrn
> demo).
>
> #Tenant,ID,Contexts,FilterIDs,ActivationInterval,FieldName,Initial,Su
> bstitute,Append,Blocker,Weight
> cgrates.org,LRN_Dst3125650565,lrn,*string:Destination:3125650565,,Des
> tination,*any,13128543000,true,false,10
> cgrates.org,LRN_Dst3125650565,,,,OriginalDestination,*any,3125650565,
> true,false,10
> cgrates.org,LRN_LATA_Dst13128543000,lrn,*string:Destination:131285430
> 00;*rsr::OriginalDestination(!^$),,DestinationLATA,*any,358,true,fals
> e,20
>
> I know.
>

Before getting into each line you should understand how the queries to
AttributeS will be looping.
We will send the Event to AttributeS in a loop. Each loop will match an
attribute profile and change some parameters. Once the parameters are
changed, the altered event will be fed again into AttributeS and match
maybe another attribute profile. If you have multiple attribute
profiles matching (by filters), the winner will be decided based on
weight (higher weight -> more priority to match).

> First line is checking if destination number is 3125650565 then
> replace it with 13128543000.
> Second line, Since destination number has become 13128543000 due to
> first line effect, lets add an attribute -> OriginalDestination of
> value 3125650565.
>
> But third line is kinda becoming abstruse to me. Could you please
> explain this last line to me especially the last part *rsr.

The third line is part of another profile (first two lines are part of
one attribute profile -> one process event).
The *rsr is an internal filter into CGRateS (RegexpSearchReplace) and
it is used as a dynamic way to match/search/replace using Regexp rules
(or some other particular rules available within CGRateS). You can call
it a special language we have developed in order to dynamically parse
content with regexp. So looking back at the line 3 that one will say:
Destination needs to be "13128543000" and OriginalDestination needs not
to be empty. The extra filter was needed so we can make sure we match
the right attribute profile (after processing the first one)
You should be able to understand more on *rsr if you look on this tests
regarding *rsr filters:

https://github.com/cgrates/cgrates/blob/master/utils/rsrfield_test.go#L313

Hope this helps.

DanB

[Aqs Younas]

Thanks DanB, for such a detailed explanation. I wish cgrates more success. 

Br, Aqs.