AutoAttendant not transferring calls in CUE 8.6 to CME 9.1

[sam saeed]

**Issue is calls are not transferring once extension or directory is pressed on the phone.

I upgraded our 2811 CME 7.1/CUE 7.0 router to 2911 15.2 CME 9.1/CUE8.6.  It has CME and V/k9 license enabled.  I uploaded the configuration used on the 2811 to the 2911.  I added the ip addresses in the ip trusted list.  Calls come in and out if I point the translation list to the phone and not to the auto attendant pilot number.  Incase if it was toll fraud issue I disabled it but still a no go.

Everything worked fine on the 2811.  I can't understand why it would not work on the 2911 15.2.  Has anyone had any issues when upgrading from 12.4 to 15.x with auto attendant not transferring calls?

I ran a trace on the Cue when placed a call to extension 114:

20.10.10.1- CME  interface address

20.10.10.5- CUE interface address

659 09/12 11:43:39.418 ACCN SIPS 0 Call.transferFailed(114, RESOURCE_NOT_ACKNOWLEDGING) SIPCallContact[id=33,type=Cisco SIP Call,implId=5738D3Dse-20-10-10-5# 8947-4E978639@20.10.10.1,active=true,state=CALL_ANSWERED,inbound=true,handled=false,locale=en_US

[Tony Cilli Jr]

15 code implements the toll-fraud prevention mechanism which has been known to throw people off going from 12.x to 15.x.

Make sure you either have a VoIP dial-peer pointing to CUE, or you add the IP of CUE to the trusted IP Address list. (you could also disable the toll-fraud prevention).

!
voice service voip
ip address trusted list
ipv4 xxx.xxx.xxx.xxx          <--  Your CUE IP Address
!

Give that shot.

[sam saeed]

Thanks for the reply.  The calls are coming in and out Toll Fraud is not the issue.  I doubled checked to see if the CUE was in the ip address trusted list.  It was in there by default.

To add I had a similar issue that I am currently having with the 2811.  These commands were enabled:

 supplementary-service sip moved-temporarily
 supplementary-service sip refer

I disabled the cmds:

no supplementary-service sip moved-temporarily
 no supplementary-service sip refer

Not sure that has to do with anything

[sam saeed]

Ok I'm starting to think its a dtmf issue. I checked to see if I call from internal to the AA and dial an extension if it works but the same issue.  I ran the debug voip ccapi inout and I see consume mask is not set.  What would that indicate?  Could that be the problem?

This is right when I dialed extension 114

2811-TEST#
001288: Sep 16 14:59:22.870: //55/D62BA3D180C8/CCAPI/cc_api_call_digit_begin:
   Consume mask is not set. Relaying Digit 1 to dstCallId 0x38
001289: Sep 16 14:59:22.870: //55/D62BA3D180C8/CCAPI/cc_relay_digit_begin_for_3way_conference:
   Check DTMF relay digit begin for 3way conf
001290: Sep 16 14:59:22.870: //55/D62BA3D180C8/CCAPI/cc_api_call_digit_end:
   Consume mask is not set. Relaying Digit 1 to dstCallId 0x38
001291: Sep 16 14:59:22.870: //55/D62BA3D180C8/CCAPI/cc_relay_digit_end_for_3way_conference:
   Check DTMF relay digit end for 3way conf
001292: Sep 16 14:59:23.194: //55/D62BA3D180C8/CCAPI/cc_api_call_digit_begin:
   Consume mask is not set. Relaying Digit 1 to dstCallId 0x38
001293: Sep 16 14:59:23.194: //55/D62BA3D180C8/CCAPI/cc_relay_digit_begin_for_3way_conference:
   Check DTMF relay digit begin for 3way conf
001294: Sep 16 14:59:23.194: //55/D62BA3D180C8/CCAPI/cc_api_call_digit_end:
   Consume mask is not set. Relaying Digit 1 to dstCallId 0x38
001295: Sep 16 14:59:23.198: //55/D62BA3D180C8/CCAPI/cc_relay_digit_end_for_3way_conference:
   Check DTMF relay digit end for 3way conf
001296: Sep 16 14:59:23.614: //55/D62BA3D180C8/CCAPI/cc_api_call_digit_begin:
   Consume mask is not set. Relaying Digit 4 to dstCallId 0x38
2811-TEST#
001297: Sep 16 14:59:23.614: //55/D62BA3D180C8/CCAPI/cc_relay_digit_begin_for_3way_conference:
   Check DTMF relay digit begin for 3way conf
001298: Sep 16 14:59:23.618: //55/D62BA3D180C8/CCAPI/cc_api_call_digit_end:
   Consume mask is not set. Relaying Digit 4 to dstCallId 0x38
001299: Sep 16 14:59:23.618: //55/D62BA3D180C8/CCAPI/cc_relay_digit_end_for_3way_conference:
   Check DTMF relay digit end for 3way conf
2811-TEST#

At this point theres silence on the phone I see this message:

2811-TEST#
001300: Sep 16 14:59:28.914: //55/D62BA3D180C8/CCAPI/ccGenerateToneInfo:
   Stop Tone On Digit=FALSE, Tone=Null,
   Tone Direction=Sum Network, Params=0x0, Call Id=55
001301: Sep 16 14:59:28.918: //56/D62BA3D180C8/CCAPI/cc_api_call_feature:
   Feature Type=50, Interface=0x49FC2B80, Call Id=56
2811-TEST#
2811-TEST#

At this point I get the message "the phone number you are trying to reach" then the call disconnects

2811-TEST#
001242: Sep 16 14:48:57.719: %VOICE_IEC-3-GW: SIP: Internal Error (ACK wait timeout): IEC=1.1.129.7.67.0 on callID 52 GUID=5D21AC143CE711E480BCEEC6B624839

Also I checked show voice iec description:

2811-TEST#show voice iec description 1.1.129.7.67.0
    IEC Version: 1
    Entity: 1 (Gateway)
    Category: 129 (Call setup timeout)
    Subsystem: 7 (SIP)
    Error: 67 (ACK wait timeout)
    Diagnostic Code: 0

2811-TEST#

[fran.saez]

I had a similiar behaviour upgrading from 15.1 to 15.2(M4) in a router 3900 and solved setting the following commands: 

LABcme00(config)#voice service voip 
LABcme00(conf-voi-serv)#supplementary-service media-renegotiate 

Our dial-peer config is like that:

dial-peer voice 11000 voip
 description ** Phone Calls to MIL **
 destination-pattern 11...
 progress_ind setup enable 3
 session target ipv4:X.X.X.X
 session transport tcp
 voice-class codec 711  
 voice-class h323 3
 dtmf-relay h245-alphanumeric
 no vad

I hope you solved your issue.. :) 

[sam saeed]

Hey there, thanks for the reply I did manage to solve my issue. I had to completely wipe out the Cue and start by scratch because copying the old config from the working nm-cue 7.0 to the nme-cue 8.6 replacement was not working and the debugs weren't telling me squat.

This was working fine on the cue 7.0:

ccn subsystem sip
 gateway address "1.1.1.1"
 mwi envelope-info
 mwi sip outcall sub-notify
 transfer-mode blind <---------
 end subsystem

I found on the Cue 8.6 the issue was the:

transfer-mode blind

I removed that on the new build and it transferred correctly

 ccn subsystem sip
 gateway address "1.1.1.1"
 mwi sip sub-notify
 mwi envelope-info
 end subsystem
 

Good thing you went to 15.2(M4) and not 15.2(M2). I went to M2 first and had sip dns errors which weren't resolving it was driving me crazy for 2 days. Apparently that was a bug in that IOS train specific to dns resolution issues with SIP servers which I luckily stumbled on someones post on here with the same issue.