Call forward not showing correct DDI

Unanswered Question
Jul 6th, 2009

Hi there.

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?

Thanks

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Skyler Spence Mon, 07/06/2009 - 08:16

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?

mfleming Mon, 07/06/2009 - 16:17

Hi Skyler

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.

Skyler Spence Tue, 07/07/2009 - 08:23

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.

mfleming Wed, 07/08/2009 - 09:44

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.

Cheers

Attachment: 
Skyler Spence Wed, 07/08/2009 - 11:32

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.

Skyler Spence Thu, 07/09/2009 - 08:55

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.

Steven Smith Thu, 07/09/2009 - 08:59

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).

mfleming Thu, 07/09/2009 - 17:18

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.

Skyler Spence Fri, 07/10/2009 - 07:42

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
trunkgroup ALL_BRI
corlist outgoing call-national
description **CCA*UK*Mobile**
translation-profile outgoing DDI
preference 4
destination-pattern 807[1-5,7-9]........
forward-digits all
no sip-register

New Translations:

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.

mfleming Mon, 07/13/2009 - 16:27

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.

Cheers

Skyler Spence Tue, 07/14/2009 - 09:18

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

conf t

logging buffered debugging

exit

clear logging

debug voice translation

Now run the test call.  Once you have completed the test call, type

show logging

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

conf t

logging console debugging

mfleming Tue, 07/14/2009 - 09:43

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?

Cheers

Skyler Spence Tue, 07/14/2009 - 10:00

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.

mfleming Tue, 07/14/2009 - 10:13

I don't understand this - I have just checked and my incoming and outgoing dialplans are completely blank. The plans were definitely there a few days ago when I made the original post. I have tried to re-add the dialplans and am being met with an error message. I haven't made any changes to the dialplans via CLI.

Am I going to have to reset the whole system to defaults now?

Attachment: 
Skyler Spence Tue, 07/14/2009 - 11:26

Are you sure you haven't made changes?  What about the change you made to the translation rule, removing the /.*/ /xx98/ rule?  I don't believe this would cause CCA to lose the dailplan configuration but it is possible.   If you don't think this is the case, do you know when it last was working?  If it was working when you posted your configuration here a few days ago I would suggest comparing that configuration to your current.  I can take a look as well if you'd like.  Another thing to check with CCA is the applcation log which can be found in the CiscoSMB folder where CCA was installed.

Skyler Spence Wed, 07/15/2009 - 07:56

I don't see any debug attached to your last post, can you try adding the attachment again?

aapexisinc Mon, 07/20/2009 - 09:34

I had the same problem, so I followed the setup to create a new dial peer with an '8' steering digit.  The translation rules all work correctly, but when I set the forward number (e.g., 81312-421-xxxx), a forwarded call does not get an outside line (as it would when steering with a 9) and the call just gets a fast-busy tone.  What did I miss?

Steven Smith Mon, 07/20/2009 - 11:15

Can you dial that number, with the 8 from the phone that you are forwarding on?

aapexisinc Mon, 07/20/2009 - 11:57

No, it won't go to an outside line when dialing '8'.  Is there a way to make either '8' or '9' go to an outside line?

Steven Smith Mon, 07/20/2009 - 12:22

Dialing 9 is done in two ways, one is for secondary dial tone, the other is to match the dial peers.  You don't need the dialing 8 to get secondary dial tone, but it sounds like your dial-peer isn't setup correctly.  When you can dial outbound with 8, this should work.

Steven Smith Mon, 07/20/2009 - 14:01

The config looks correct.  If you can't dial outbound with this, then I would suggest opening a TAC case.  You might be hitting a different dial-peer than you think you are.

mfleming Tue, 07/21/2009 - 05:07

Skyler, I fiddled around with the translation in CLI and seem to have got this working now - it now passes through the number that is calling, instead of the office number. However, in the process, I seem to have removed the ability to tie an outgoing DDI to an extension when dialing out from the phone. For example, it used to be when I dialed from 201, it would show the 98 number, and 202 would show the 10 number. This is no longer the case, however the DID to these numbers go to the correct extensions.

Could you advise me what to look for in command line to try to correct this? I'm afraid CCA isn't possible, as I'm not in a position to be able to reset to factory defaults to be able to configure the dialpeer by CCA.

Marcos Hernandez Fri, 07/24/2009 - 07:19

Can you explain exactly what the number looks like when calling from 201 and 202, and what it should be?

Thanks,


Marcos

mfleming Wed, 07/29/2009 - 08:42

Hello Marcos. It basically appears that none of the outgoing translations are working. The forwarding WAS working but seems to no longer be. The incoming translations are working fine.

I have two BRI connected to the UC500 with two associated PSTN numbers. I had the dialing rules set up so that when you dialled from 201 it showed one PSTN number, and when you dialled from 202 it showed the other. At the minute this is no longer working, and the PSTN number seems to be chosen randomly, i.e. sometimes it shows one number to the person being called, and other times the other number.

The same goes for the call forwarding. If someone calls into my phone and the phone is set to forward to my cell phone, it forwards the call to me, but again shows one of the PSTN numbers at random. I would like it to either show my PSTN number (instead of a random one) or to pass through the digits from the calling number.

At the minute I can't use CCA as I must have made out-of-band changes and I am not in a position to be able to reset to defaults at the minute.

I hope this made sense to you,

Thanks.

Actions

This Discussion