03-17-2021 05:56 AM
When our client is making outgoing calls, the receiving party is seeing the wrong number. The example I have is as follows:
Client makes a call - person receiving call sees 123-456-789. The last digit isn't showing. As a result, their number is often listed as Spam or shows the call coming from South Africa. We need the full 10 digit number. What should I be looking for to accomplish this?
Solved! Go to Solution.
03-17-2021 06:00 AM
Check if there is any translation. if you can share the configuration hiding confidential information we can have a look.
03-17-2021 06:00 AM
Check if there is any translation. if you can share the configuration hiding confidential information we can have a look.
03-17-2021 06:10 AM
03-17-2021 06:48 AM
You have two different translation profiles applied outbound to the trunk group, and to the individual members. I am not sure which would take precedence so I would have a look at the two and see which one looks correct.
On the dial peers you have the profile "Windstream200-out" which used voice translation-rule 206 to convert calling numbers
The trunk group uses "Windstream200-trunk-out" using voice translation-rule 255
Can you take a debug of an outbound call and see what you're actually sending. "debug isdn q931"
03-18-2021 06:44 AM
03-18-2021 07:26 AM
OK, so you're sending a 10 digit calling number "5555553385". Is that the correct number, the one you expect the called party to see as caller ID? It doesn't match any of your translation rules, as noted rule 255 only changes type and plan to "unknown" and doesn't change he number at all. Rule 206 would change any of the listed extension numbers to "1234567895", and the catch all at the end would change any number not matched to a default of "11234567895".
So where is that number "5555553385" coming from?
Can you get any information from the carrier about what format the require for the number, and also if they require specific values for "type" and "plan".
FYI in some cases I have had to resort to guess work to get the calling party number in a format that the carrier expected. And I've also known carriers where some change, not properly explained to the customer, suddenly made then stop working until another spell of guesswork to find the format they now need. However in those cases I know the country and the carrier and the actual numbers.
To start the process of guesswork, could you get a debug from an incoming call from a local, and from a national number? Let's see how the carrier presents calling numbers inbound.
03-18-2021 07:40 AM
First, Thank you kindly for the input and help! Yes 555-555-3385 is the correct number. We want this to be the blanket number for all outbound calls. I will work on getting the additional debug and try to determine what the carrier requires for type/plan. If there's something I could try now in the mean time to see if that corrects the issue, let me know.
03-18-2021 08:23 AM
OK I suggest removing voice translation rule 255, or remove it from the profile if you prefer. Then in rule 206 if you want all calls to present the same number, you could get rid of all the individual translations and replace with a single line. Maybe create a new rule and reference that in the profile as an easy way to revert. While you're at it you could try setting Type to National and Plan to ISDN. Putting those together we would have something like this.
voice translation-rule 207 rule 5 /^.*$/ /5555553385/ type any national plan any isdn voice translation-profile Windstream200-out translate calling 207 translate called 208 translate redirect-target 209 translate redirect-called 206
Try with and without the "plan any isdn" and with and without the "type any national".
I'm assuming in your country that 10 digits is in fact the National number format, but it's a guess at this stage.
Good luck.
03-18-2021 11:18 AM
From debug you shared all outgoing calls you made shows calling number '5555553385'.
Asper your first post "Client makes a call - person receiving call sees 123-456-789. The last digit isn't showing"
what's you exact requirement.
Translation @TONY SMITH shared will convert everything to 5555553385, is that your requirement ?
03-17-2021 07:05 AM
From which extension are you calling ?
you can check if the rule works or not from CLI using below command.
test voice translation-rule 206 callingnumber
voice translation-rule 255
rule 1 // // type any unknown plan any unknown >>> this will effect only the type.
jlrvg#test voice translation-rule 255 123
Matched with rule 1
Original number: 123 Translated number: 123
Original number type: none Translated number type: unknown
Original number plan: none Translated number plan: unknown
jlrvg#test voice translation-rule 255 1000
Matched with rule 1
Original number: 1000 Translated number: 1000
Original number type: none Translated number type: unknown
Original number plan: none Translated number plan: unknown
04-01-2021 06:06 AM
Thank you to everyone for your input. I ended up determining that I needed to modify 'voice translation-rule 206' to include missing extensions. After adding respective rules, the issues are now solved. Thanks again everyone!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide