Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

AutoAttendant not transferring calls in CUE 8.6 to CME 9.1

**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

 

 

 

5 REPLIES

15 code implements the toll

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.

New Member

Thanks for the reply.  The

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

 

 

 

New Member

Ok I'm starting to think its

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#

New Member

I had a similiar behaviour

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

 

New Member

Hey there, thanks for the

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.

 

416
Views
0
Helpful
5
Replies