Hi Yeti,
I have discovered that in the Customers Auth menu, if I select both the DST Numberlist to filter the destination number and need to add a prefix to the destination number (for routing and billing purposes), the Customers Auth will first add the prefix to the destination number and then validate it through the DST Numberlist, causing the DST Numberlist to fail.
I’m not sure if this is a bug or an issue with the routing logic. Thank you.
This is expected behavior. Could you explain your use case why you adding prefix in customer auth?
Hello, thank you for your response!
When calls come from customers Auths into yeti, I use number translation and dst rewrite to add a prefix for routing and billing (I’m not sure if my actions are correct).
However, I don’t quite understand: customers Auths first execute dst rewrite, and then use the dst numberlist to filter the B-number logic.
Additionally, I am from China. In China, the call rates for dialing different provinces and cities are usually the same, so we generally do not route and rate calls based directly on the called number prefix. Instead, we add a special prefix to the B-number, such as 888 or a23… And use this special prefix for billing. Therefore, I need to add a prefix to the called number.
What exactly is not clear for you? dst rewrite in customers Auth usually required to normalize number received from call originator - remove tech prefix, remove 00, +. Numberlists processing will be done after this rewriting.
Instead, we add a special prefix to the B-number, such as 888 or a23…
It is still not clear why you need this special prefix and what logic of this adding. Could you explain based on what rules this prefix assigned?