Solved: Sip phone with UC560 / CME

Viastak Support · ‎10-06-2014

Hi,

I have registered a Polycom IP Soundstation 5000 SIP phone with a UC560 (CME) system.

Internal calls work in both directions.

External calls work inbound but not outbound.

I ran "debug voip ccapi inout" and found that the dialed number has "ABCD" put in front of it:

043265: //-1/FBFA050185DC/CCAPI/cc_api_display_ie_subfields:
   cc_api_call_setup_ind_common:
   cisco-username=6044
   ----- ccCallInfo IE subfields -----
   cisco-ani=6044
   cisco-anitype=0
   cisco-aniplan=0
   cisco-anipi=0
   cisco-anisi=0
   dest=ABCD907584449552
   cisco-desttype=0
   cisco-destplan=0
   cisco-rdie=FFFFFFFF
   cisco-rdn=
   cisco-rdntype=0
   cisco-rdnplan=0
   cisco-rdnpi=-1
   cisco-rdnsi=-1
   cisco-redirectreason=-1   fwd_final_type =0
   final_redirectNumber =
   hunt_group_timeout =0

043266: //-1/FBFA050185DC/CCAPI/cc_api_call_setup_ind_common:
   Interface=0x875A0A64, Call Info(
   Calling Number=6044,(Calling Name=)(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed),
   Called Number=ABCD907584449552(TON=Unknown, NPI=Unknown),
   Calling Translated=FALSE, Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE,
   Incoming Dial-peer=40001, Progress Indication=NULL(0), Calling IE Present=TRUE,
   Source Trkgrp Route Label=, Target Trkgrp Route Label=, CLID Transparent=FALSE), Call Id=78945
043267: //-1/FBFA050185DC/CCAPI/ccCheckClipClir:
   In: Calling Number=6044(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed)
043268: //-1/FBFA050185DC/CCAPI/ccCheckClipClir:
   Out: Calling Number=6044(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed)
043269: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

043270: :cc_get_feature_vsa malloc success
043271: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

043272: cc_get_feature_vsa count is 31
043273: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

043274: :FEATURE_VSA attributes are: feature_name:0,feature_time:2386993696,feature_id:18675
043275: //78945/FBFA050185DC/CCAPI/cc_api_call_setup_ind_common:
   Set Up Event Sent;
   Call Info(Calling Number=6044(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed),
   Called Number=ABCD907584449552(TON=Unknown, NPI=Unknown))
043276: //-1/xxxxxxxxxxxx/CCAPI/cc_build_feature_vsa:

043277: :Inside cc_build_feature_vsa
043278: //-1/xxxxxxxxxxxx/CCAPI/cc_build_feature_vsa:

043279: feature call basic
043280: //-1/xxxxxxxxxxxx/CCAPI/cc_build_feature_vsa:

043281: cc_build_feature_vsa attr is fn:TWC,ft:10/06/2014 10:21:27.555,cgn:6044,cdn:ABCD907584449552,frs:0,fid:18675,fcid:FBFA05014C7011E485DCF6602ADD1E8F,legID:13461
043282: //78945/FBFA050185DC/CCAPI/cc_process_call_setup_ind:
   Event=0x885AFB08
043283: //-1/xxxxxxxxxxxx/CCAPI/cc_setupind_match_search:
   Try with the demoted called number ABCD907584449552
043284: //78945/FBFA050185DC/CCAPI/ccCallSetContext:
   Context=0x8C58C908
043285: //78945/FBFA050185DC/CCAPI/cc_process_call_setup_ind:
   >>>>CCAPI handed cid 78945 with tag 40001 to app "_ManagedAppProcess_Default"
043286: Oct 6 10:21:27.563: %AAA-3-BADSERVERTYPEERROR: Cannot process accounting server type radius (UNKNOWN)
043287: //78945/FBFA050185DC/CCAPI/ccCallProceeding:
   Progress Indication=NULL(0)
043288: //-1/xxxxxxxxxxxx/CCAPI/cc_setupind_match_search:
   Try with the demoted called number ABCD907584449552
043289: //-1/xxxxxxxxxxxx/CCAPI/cc_update_feature_vsa:

043290: : updating existing feature vsa
043291: //-1/xxxxxxxxxxxx/CCAPI/cc_update_feature_vsa:

043292: feature call basic
043293: //78945/FBFA050185DC/CCAPI/ccCallDisconnect:
   Cause Value=17, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=0)
043294: //78945/FBFA050185DC/CCAPI/ccCallDisconnect:
   Cause Value=17, Call Entry(Responsed=TRUE, Cause Value=17)
043295: Oct 6 10:21:27.587: %VOIPAAA-5-VOIP_CALL_HISTORY: CallLegType 2, ConnectionId FBFA05014C7011E485DCF6602ADD1E8F, SetupTime 10:21:27.557 BST Mon Oct 6 2014, PeerAddress 6044, PeerSubAddress , DisconnectCause 11 , DisconnectText user busy (17), ConnectTime 10:21:27.587 BST Mon Oct 6 2014, DisconnectTime 10:21:27.587 BST Mon Oct 6 2014, CallOrigin 2, ChargedUnits 0, InfoType 2, TransmitPackets 0, TransmitBytes 0, ReceivePackets 0, ReceiveBytes 0
043296: //-1/xxxxxxxxxxxx/CCAPI/cc_build_feature_vsa:

043297: :Inside cc_build_feature_vsa
043298: //-1/xxxxxxxxxxxx/CCAPI/cc_build_feature_vsa:

043299: feature call basic
043300: //-1/xxxxxxxxxxxx/CCAPI/cc_build_feature_vsa:

043301: cc_build_feature_vsa attr is fn:TWC,ft:10/06/2014 10:21:27.555,cgn:6044,cdn:ABCD907584449552,frs:1,fid:18675,fcid:FBFA05014C7011E485DCF6602ADD1E8F,legID:13461
043302: Oct 6 10:21:27.587: %VOIPAAA-5-VOIP_FEAT_HISTORY: FEAT_VSA=fn:TWC,ft:10/06/2014 10:21:27.555,cgn:6044,cdn:ABCD907584449552,frs:1,fid:18675,fcid:FBFA05014C7011E485DCF6602ADD1E8F,legID:13461,bguid:FBFA05014C7011E485DCF6602ADD1E8F
043303: //78945/FBFA050185DC/CCAPI/cc_api_call_disconnect_done:
   Disposition=0, Interface=0x875A0A64, Tag=0x0, Call Id=78945,
   Call Entry(Disconnect Cause=17, Voice Class Cause Code=0, Retry Count=0)
043304: //78945/FBFA050185DC/CCAPI/cc_api_call_disconnect_done:
   Call Disconnect Event Sent
043305: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:

043306: :cc_free_feature_vsa freeing 8E46A218
043307: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:

043308: vsacount in free is 30

I can see the following translation rules which I believe are responsible. They are built in as part of CUE but I'm not sure what they are for:

voice translation-rule 411
rule 1 /^9\(.*\)/ /ABCD9\1/
!
voice translation-rule 412
rule 1 /^ABCD\(.*\)/ /\1/
!
voice translation-rule 422
rule 1 /^ABCD909[01]......../ //
rule 2 /^ABCD9090[89]......./ //
rule 3 /^ABCD9098\(.*\)/ //
rule 15 /^ABCD\(.*\)/ /\1/

===

voice translation-profile SIP_Incoming
translate called 411
!
voice translation-profile SIP_Passthrough
translate called 412
!
voice translation-profile SIP_Passthrough_CallBlocking
translate called 422

===

How can I avoid outbound calls from the SIP phone from hitting these rules or is there something else going on which I'm not aware of?

Thanks

Jayanth Velkuri · ‎10-07-2014

I would remove below

voice source-group CCA_SIP_SOURCE_GROUP_CUE_CME
 access-list 2
 translation-profile incoming SIP_Incoming

and test .

View solution in original post

aseanand89 · ‎10-07-2014

Kindly send us the running configuration of the CME so that we can see where the translation profiles are applied and from where it is getting invoked.

Viastak Support · ‎10-07-2014

Config attached. i have removed some passwords and IP addresses.

thank you.

Jayanth Velkuri · ‎10-07-2014

I would remove below

voice source-group CCA_SIP_SOURCE_GROUP_CUE_CME
 access-list 2
 translation-profile incoming SIP_Incoming

and test .

Viastak Support · ‎10-07-2014

thanks that worked.

im a bit concerned about what this code does though. according to another post:

https://supportforums.cisco.com/discussion/11282411/voice-source-group-ccasipsourcegroupcuecme

"This is a bit of a hack.

There's an incoming dial-peer on the router which matches all incoming calls (unless a specific DID has been configured) and rejects the call. The dial-peer has "permission term" configured. This is part of the toll fraud / anti loop mechanism which configured the router to only accept incoming calls placed to numbers which are configured on the system.

Remembering that the Unity module is a separate SIP UA, calls from CUE destined to PSTN would fail because of this, so what they've done is prefix incoming calls from networks described by access-list 2 (i.e. the CUE module) with ABCD. We then have an incoming dial-peer which matches calls starting ABCD, this is removed and the call is successful."

Why would unity need to call the PSTN?

Voicemail seems to be working.

Jayanth Velkuri · ‎10-07-2014

i think if you use CCA , it configures those xlation rules for some reason