Auto Attendant External Transfer Not working

[mark]

Hello,

I have a AA script at a doctors office that is supposed to transfer to an answering service after hours.  It used to work just fine when they were using analog lines.  I recently moved them to an ISDN PRI and it stopped working.  Same script, same number, nothing changed except for the new connection.  I figure it is some kind of toll fraud prevention measure that I need to disable.  I tried adding the checkmark to allow external transfer, and even adding a transfer patter with the exact number.  Internal transfers work fine. Hope you can help me out.

Thanks,

[Darren DeCroock]

Mark,

Most likely the issue is that the PRI provider is rejecting the call, since the Caller-ID is listed as the original caller.

If this is the case, the only way around this would be to translate the caller ID so that the call appears to be coming from one of your DID's.

The easiest way to do this would be to create a ougoing translation on the PRI trunkgroup to translate the calling number on all outgoing calls.

Example:

trunk group ALL_T1E1
hunt-scheme longest-idle
translation-profile outgoing PROFILE_ALL_T1E1

voice translation-profile PROFILE_ALL_T1E1
translate calling 4

voice translation-rule 4
rule 1 /.*/ /5551118888/

Would need to see your config, to give exact steps/settings.

Note:  Disadvantage of this, is that all calls/transfers would then appear to be coming from your office, and not the original caller.

Thank you,

Darren

[mark]

Darren,

I already have that in there.  The funny thing is that I have two UC560's doing the same thing and one that works just fine.  If I call the AA from the inside and push 0, it transfers me to the external number just fine.  If I call, and the receptionist and she transfers me to that external number, it works just fine.  It is only when calling from outside, to the AA, that I get a busy signal when it trys to transfers me.  I compared configs from the UC560 that works to the two that don't work and I can't find anything different!  The IOS and CUE are the same version all all three!

What debugs or configs do you need me to give you.  It is probably something easy, I have seen other posts where there is an Allow External-to-External that you need to set to "true" but the UC560 doesn't have that command I believe.

Thanks,

[Steven DiStefano]

If using CCA, R U sure you have the little 'allow external transfer' box checked in AA GUI?

[mark]

Steven,

That is the first thing I checked.  Another wierd thing is that it was working just fine with analog lines.  It is only when we switched to a PRI that it stopped working.  I have even tried to "trick" the phone system by creating a dummy internal extension that has a call-forward all to the outside number and it still gives me the busy signal.

[Darren DeCroock]

Mark,

Can you get a debug, so we can see what is happening with the call, and if the translation is working correctly?

debug voice ccapi inout

debug isdn q931

Thank you,

Darren

[mark]

I have attached the files.  Let me know what you find.

Thanks,

[Jontheuser]

031177: Feb 10 02:43:56.734: ISDN Se0/3/0:23 Q931: RX <- DISCONNECT pd = 8  callref = 0x8E16
Cause i = 0x8295 - Call rejected

http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/dbook/disdn.htm

0x8295
8= ITU standard
2= from public network to user
95 (hex) =  1001  0101

drop high order bit, result is 001  0101
back to hex = 15
look from above url (for HEX value) .... Your destination is accespting call but rejecting for some reason

031176: Feb 10 02:43:56.634: ISDN Se0/3/0:23 Q931: RX <- CALL_PROC pd = 8  callref = 0x8E16
Channel ID i = 0xA98382
  Exclusive, Channel 2

isdn negotiate-bchan
To enable the router to accept a B channel that is different from the B channel requested in the outgoing call setup message, use the isdn negotiate-bchan command in Interface Configuration Mode. To restore the default condition, use the no form of this command.

Command default

B channel negotiation is not enabled. Most PRI switch types set the default channel ID to Exclusive in the setup message. An exception is the NI2 switch, which sets the default to Preferred.

Usage Guidelines
The isdn negotiate-bchan command enables the router to negotiate the B channel by setting the channel ID information element to Preferred in the setup message. If this command is not configured, the channel ID is set to the default of the switch, which is usually Exclusive. Exclusive means that only the requested B channel is accepted. If the requested B channel is not available, the call is cleared.

[mark]

I added the command and I still get the same issue.  I ran the debug and it looks exactly the same.

[Darren DeCroock · Accepted solution]

Mark,

I looked at the debugs, and the caller-ID is still not being translated.  You are sending the caller ID of the original calling party.

031175: Feb 10 02:43:56.622: ISDN Se0/3/0:23 Q931: TX -> SETUP pd = 8  callref = 0x0E16
Sending Complete
Bearer Capability i = 0x8090A2
  Standard = CCITT
  Transfer Capability = Speech 
  Transfer Mode = Circuit
  Transfer Rate = 64 kbit/s
Channel ID i = 0xA98382
  Exclusive, Channel 2
Calling Party Number i = 0x2180, '9157903967'
  Plan:ISDN, Type:National
Called Party Number i = 0xA1, '5755282169'
  Plan:ISDN, Type:National
031176: Feb 10 02:43:56.634: ISDN Se0/3/0:23 Q931: RX <- CALL_PROC pd = 8  callref = 0x8E16
Channel ID i = 0xA98382
  Exclusive, Channel 2
031177: Feb 10 02:43:56.734: ISDN Se0/3/0:23 Q931: RX <- DISCONNECT pd = 8  callref = 0x8E16
Cause i = 0x8295 - Call rejected

I believe that is why your provider is rejecting the call.

Thank you,

Darren

[mark]

Darran,

You were right, I should have double checked the translation profile.  It is the one that the CCA automaticaly creates, but it looks like it was only translating internal numbers. .  I looked at your notes and copied one off of another customer that I configured manually without the CCA and it resolved the issue.  I am trying to use the CCA more but it's little things like this that drive me crazy.  I do admit it is getting better though.  Thank you very much for helping me out.  One less headache to deal with.