I have a simple two BRI setup with two telephone numbers, one ending 98, the other ending 30. I have only two telephones and I have a incoming and outgoing dialplan which says calls coming in on 98 go to one phone, and calls coming in on 30 go to the other. The same applies for outgoing calls, each phone shows their specific DDI.
My problem is when I enable call-forwarding on the phone ending 30. If I forward it to my mobile, any calls forwarded to me are forwarded showing the 98 number and not the 30 number. This is only a minor inconvenience, but it means I am unable to tell if it is a call from my colleague on 98 or a call forwarded to me, until I answer the call.
Is there a way I can change this to show the correct DDI?
Is this being seen with all types of call forwarding, or only one? For example, does call-forward no answer work and call-forward all does not? One thought, which number is set as your default caller id?
Call when not answered goes directly to voicemail. The 98 number is listed as the "Main PSTN number", and I have the outgoing plan set to "Use DDI" when dialing out so the correct number appears when dialing normally, but not with call forwarding - it always shows this main number.
Can you please attach your configuration with the passwords removed? I'd like to check out your dial plan information and see if there is anything wrong there.
Hi Skyler, have attached full config.
I have noticed that it does not always use the 98 number, it seems to switch between either one, and randomly. I have made a few test calls from another mobile and sometimes it displays xx98, others it displays xx10. There doesn't appear to be any method to this, just random whatever number comes out.
What I suspect is happening here is that the calling number never gets changed to the extension, it is remaining as the calling number of your cell phone. Because of this, the translation rule is being hit for the /.*/ /xx98/ statement. You can confirm what numbers are being sent in and out of the system using the debug isdn q931 command. I believe that this is actually the desired behavior, so that when the call is forwarded externally (to your cell phone for example) you can see the number of the calling party instead of just your office number. This is without the catch all translation rule of course. Check out what your system is sending and receiving using that debug, and I'll look into what is expected behavior here.
Removing the catch-all translation rule will cause the caller id to show the cell phone number that called the UC500, in your test case "xx28" will be displayed. This is desirable for many deployments in that the calling party can be identified on your cell phone rather than just having the knowledge that the call is being transferred by your office phone. If you are interested though, I may have an idea for forcing the caller id to be the correct "xx10" number using class of restriction lists. Let me know if you are interested and I'll configure and test it on my system then pass it along to you.
Another way to fix this is to create a dial-peer for your forwarding. Have it use a different steering digit and translation rule. When you would forward your phone, you could forward to 7, then your number (or something similar).
Hi Skyler, I would prefer for the calling number to be shown on my cell phone and not the office DDI, but this is not essential - at least I would just like the correct DDI number. I have removed the catch all rule from the translation 1111 and it has made no difference? I'm intrerested in why it hasn't worked. Either way, I am grateful for any help, or any other method you might suggest.
Steve - I've only been working with the UC500 a week or so and wouldn't be 100% on doing that. If you have a sample config, I'll be happy to try it.
After removing the statement
rule 15 /.*/ /xx98/
from voice translation-rule 1111 the caller-id is still being shown as "xx98"? Could you please enable "debug voip dialpeer" and attach the ouput from your test call? This should show us more information.
For Steven's suggestion, you would take one of your existing dial-peers as an example, copy it, and change only the destination pattern and translation profile. Then create a translation rule that matches whatever caller-id you want to output. Finally, change the call-forward on your ephone-dn to match the destination pattern of the new dial-peer with steering digit. For example:
New Dialpeer (steering digit=8):
dial-peer voice 555 pots
corlist outgoing call-national
translation-profile outgoing DDI
voice translation-profile DDI
translate calling 555
voice translation-rule 555
rule 1 /.*/ /xxxx/
This would force all calls steered with an 8 going to a cell to use this dialpeer, which uses this translation profile to translate all calling numbers to xxxx.
Hi Skyler - attached the debug output from the test call. Caller ID showed xx10 number this time, but second time I tried it showed the xx98 number so it seems to choose one randomly. Maybe you can make sense of the debug. I will try the new dialpeer if all else fails.
Everything here seems to be working fine...matching the correct dial-peers which matches with the desired translation profile. The fact that the same call sequence can result in either xx98 or xx10 being chosen is very puzzling. In fact, this should not be possible! One final debug request, and then we should either open a TAC case or go with Steven's workaround. Can you do the following for me? Session into the box and enter
logging buffered debugging
debug voice translation
Now run the test call. Once you have completed the test call, type
and attach that output here. Don't forget to turn off the debugging. To return the debugging output to the console screen rather than the logs, type
logging console debugging
Hi Skyler - requested debug output attached.
One thing - when a call comes in, the system seems to drop the leading 0. Is this accepted behaviour or could this be the cause of the problem? For example, if someone calls from 07123456789, then the system shows 7123456789. Hope that makes sense.
P.S. Would you like me to try Steve's workaround or do you want to continue with solving the problem in other ways?
According to this debug, there is no translation occuring on the calling number. The only translation rule being invoked is the 9 being stripped from the called number of 9xx22. The lack of a translation rule being hit, along with the randomness as to which number is showing up as caller id, leads me to think that your outbound caller id is being determined by which BRI port the call uses. To test this, we would need to look at the output from
debug isdn q931
for a call with both caller-ids xx10 and xx98. I am willing to bet that each of those caller-ids leaves from a different port. This same debug will show you if a call comes in with the leading 0, this is not the first time a UK customer with a BRI has not been receiving the leading 0 from the telco.