09-12-2014 09:16 AM - edited 03-17-2019 12:08 AM
**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
09-12-2014 12:02 PM
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.
09-12-2014 01:30 PM
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
09-16-2014 08:05 AM
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#
10-29-2014 10:41 AM
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.. :)
10-29-2014 11:56 AM
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.
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