Are your "segments" exclusively based on Geography?
Perhaps we can come up with some way segmenting the destination set into logical groups, and then use those groups within your Routing Groups.
Normally we divide the destination sets on the basis of country but some time we need to do further division with in the country for example in case of UAE ... we divide UAE into DU, Etisalat and Fixed network destination sets. For clarity i am further explaining the idea w.r.t UAE and Pakistan destination
1) My vendor A is offering me UAE and Pakistan, i have made tariff "A-Rates" for them which has UAE and Pakistan included
2) I want to use vendor A for DU Network of UAE, for this I have made a routing group "UAE DU Premium" and made a destination set "A UAE DU" for Vendor A which only contains the UAE DU dial Codes with routing preferences
3) When ever call goes on that routing group it will use the dial codes present in A UAE DU for the routing and take the rates from the A-Rates tariff.
In Sippy destination sets are used for the routing and rate implementation which is making difficult to make rate implementation on vendor... for example i have a vendor A on which i send USA, UK, UAE traffic and for each country i have made individual routing group then in this case i need to make three destination sets for the similar vendor and when ever the rate change comes i need to modify that particular destination set which creates lot of problems, also there are other complex cases of routing which require implementation of multiple destination sets even for a single country routing. I think tariff of the vendor should be called from the main vendor account ( just like in reseller) and that should be combined by system itself for the routing in a dynamic way (combination is require for LCR routing only).
For me thats the most time taken place where my engineers make lot of mistake due to multiple implementation and its not even easy to automise via any third party system.
1 person likes this idea