Showing results for 
Search instead for 
Did you mean: 


Packaged CCE - CVP transfer problem

I have on my customer a Packaged Contact Center Enterprise 9, I configured a ICM script with two options menu, the first option transfer calls for a skill group, the second option transfer the calls for a static label (835913) where 83 is the code of a trunk route. There is a Dialed Number Pattern 835913 on CVP: 835913 (Ex: local static route -

Worked normally since the implementation (02 months ago) and now not working very well, about half of the calls that go for option 2 are not transferred to the number 835913, when the problem happening generates the following log:

1460: Apr 23 2013 23:39:07.123 -0300: %CVP_9_0_SIP-3-SIP_CALL_ERROR:  CALLGUID = E119DF28ABBE11E295B1C03759BA26DA LEGID = E11A7B50-ABBE11E2-95B6C037-59BA26DA - [INBOUND]: Refer failed with 487 - Request Terminated. May be a problem with Routing Configuration or Gateway Dial-Peer. [id:5004]

1462: Apr 23 2013 23:39:07.123 -0300: %CVP_9_0_SIP-3-SIP_CALL_ERROR:  CALLGUID = E119DF28ABBE11E295B1C03759BA26DA LEGID = E11A7B50-ABBE11E2-95B6C037-59BA26DA - [INBOUND] - ABNORMALLY ENDING - SIP code [480], Reason Hdr [SIP;cause=480] Temporarily Not Available, GW call using SURV TCL flag [false], NON NORMAL flag [true], DNIS [7767], ANI [11991182252] with AGE (msecs) 40685 and Call History : 77711110008166|-1;835913|1; [id:5004]

I have not found anything about. Does anyone know this problem?

Senthil Kumar Sankar
Cisco Employee


From the Log snippets, what i could guess is CVP is sending a SIP REFER to the Gateway, and probably Gateway failed this call, due to some reason.(not sure why)

Anything changed on the gateway side like dial-peer ? Do you have complete CVP Call Server logs, for this specific call ?

Also do you get the call from T1/E1 or it is IP Call from Service provider ?



Hi Senthil,

I believe that there are no changes, please may you see the attach dial-peers that deliver calls to this application?

The calls are received through a circuit E1.

this is the route-pattern that transfer the calls to another cluster (option 2 menu):

Inter Cluster Trunk:



VoIP Corporativo GCC


When I call to 835913 no have problems.



Hey Cris,

That Refer thing happens while CVP sending 92929292 to Gateway to play errortone, before that CVP gets ths Label

835913 from ICM. CVP mathes the StaticRoute and RONA (15seconds) and sends the Sip Invite to CUCM, but for some reason CUCM rejects with 480 Sip Cause Code.

Checked the Logs, I could see that the CVP sends an SIP INVITE message to the cucm.cimporbr.cimpor.root Apr 23 2013 23:38:35.689 -0300: %CVP_9_0_SIP-7-CALL:  {Thrd=pool-1-thread-264-SIP-421} CALLGUID = E119DF28ABBE11E295B1C03759BA26DA LEGID = E119DF28ABBE11E295B1C03759BA26DA-136677111568952 - [OUTBOUND]: INVITE TO <835913> FROM 11991182252 <11991182252> EXPIRES[15] 100REL[Unsupported] Apr 23 2013 23:38:35.814 -0300: %CVP_9_0_SIP-7-CALL:  {Thrd=DIALOG_CALLBACK.6} CALLGUID = E119DF28ABBE11E295B1C03759BA26DA LEGID = E119DF28ABBE11E295B1C03759BA26DA-136677111568952 - [OUTBOUND] - DsSipInvitation - <835913>;tag=42059~e34f47f0-177c-47d0-9e2e-2d1d50e0b9e8-65002070 - 1 REJECTED WITH 480 - Temporarily Not Available

How exactly the 835913 is configured in CUCM. Can you check from CUCM side all the configs. Not sure why CUCM would reject this Invite. Need to investigate from CUCM perspective.

There are some considerations for RONA in CVP as well. Have a look at the below document.

You could also check the Logs from CUCM side what happens for this SIP INVITE.

From CVP enable detailed traces, which shows the complete SIP messages.



I will extract the CUCM logs to find more information about, but why with RONA this?

Assuming you have the RONA timer hierarchy is follwed as per the document.

If i just think of the 480 Cause code, It tells that the destination 835913 was not ready to accept the Invite. How exactly this is used in CUCM. You can also verify the CSS/Partitions for this specific DN in CUCM.

I was also looking the complete CVP logs, I believe you have extension starting from 8XXX. Can you check is there anything Overlapping in CUCM with the above number. You  Can check in CUCM using Route Plan Report under Call Routing.

If the CVP if you would have the detailed SIP Traces enabled, There would be Reason comes with 480, from that we can guess what should be the problem.



Please use the star ratings to help drive great content to the top of searches.

The other end cluster doesnt have the correct configuration, is a cluster (01 pub + 02 subs), but was configured intercluster for pub and 01 sub, after the setup a second subscriber on intercluster now works fine.

Great you figured out something in CUCM side. But as far as I know Intercluster Trunks are used when there is need of communication to another cluster, If all three nodes are in one cluster, you don't need intercluster trunks

Please use the star ratings to help drive great content to the top of searches.



Call answered by menu option 2 are transfered for another cluster... this cluster is managed by other technical team.

Content for Community-Ad