Agent reserved but no call

[iptuser55]

We have an agent where initial the ' call ' would fail.. It turned out that the new agent DN range was not created in the dial pattern in cvp now added the DN range and pointed the route to the cucm

The call now works with the agent being reserved but can not connect.  What am I missing, 

If the system was UCCX then if may be cti css route point issue but we are using ucce so my understanding the route to an agent from icm is just the cvp dial pattern,  cvp sip trunk to CUCM.  all calls come from the  PSTN gw>>>>cvp>>>>icm and so for the ICM to send the call to the agent is 

ICM>>>>cvp>>>>>cvp sip trunk>>>>cucm

Is this correct? 

Another question 

Does there need to be a sip trunk back to cvp? 

Thanks 

[Chintan Gajjar]

what do you mean SIP trunk back to CVP? the SIP trunk between CUCM and CVP is enough for bi directional traffic.

can you attach CVP logs(both ERROR and CVP) from C:\cisco\CVP\logs for problematic call to look at more in detail.

[iptuser55]

Ive got it  working using a new Dialed number prefix which was already configured in CVP as a sip trunk to CUCM.

 I then changed the new "working" agent DN for a different Partition which resulted in the agent failing again. This has led me to believe that the new SIP dial number pattern which I created either is not working or a fault with the partition. If it is a partition issue then that should be easy to resolve by adding the missing partition in the inbound CSS of the cvp SIP trunk but the issue I have is that I can not see the "working" route pattern/ SIP trunk which is pointing to CVP. The CUCM does not have a sip trunk to CVP but goes via a GW and then to CVP

If there is not SIP trunk from CUCM to CVP , but there is a SIP trunk from CVP to CUCM how does it work, what CSS is assigned

I suppose the question is does the CVP dial number which is pointing to CUCM need a SIP trunk going back to CVP 

If there is a SIP trunk from CVP to CUCM  why can I not see in CUCM , should I see it or is it taken that the SIP trunk exist is one way CVP to CUCM. If this is so how you can control what Partitions, DNs it can see

thanks

[iptuser55]

hi again

Ive done some more investigation from various videos Ive seen it seems the following is the work, call flow

after queue to skill set 

step 1 ICM sends an agent label back to CVP - call agent 1234

step 2 CVP has a static route of 12* to send all calls with a prefix of 12 to CUCM 

step 3 CVP sends signalling via this SIP trunk

step 4 CUCM answers

step 5 CVP then instructs the GW - PSTN access in our case to send RTP to the agent

Question

For step 5 to work, the GW must have a dial-peer of 12* to the CUCM - is this correct

Was the CVP dial-number route only used for signalling NOT the actual transfer, RTP route?

This seems correct as I can not see any inbound SIP trunk between CVP and CUCM. As I stated from my basic tests, changing to a partition of a successful , whose partition which is used as a limited internal form stops the call being offered e.g if I assigned a partition of say "pick up only " something which assigned to no trunk type CSS the agent is not offered the opportunity to answer the calls

What is the CVP dial-number patterns used for

Is it the GW dial-peers which need to see the agent,

CVP pass the "call" back to the gw to instruct the gw to make the actual transfer? 

thanks

[Chintan Gajjar]

I am really not able to follow your some of the questions but let me try to answer.

First of all SIP Trunk is CUCM term and not with CVP, you create trunk on CUCM with CVP or gateway for inbound and outbound calls.

on gateway you for same functionality you have dial-peers.

and on CVP for the same function you have static routes and dialed number pattern.

Now for agent label, CVP can have various ways to get connected CUCM.

1. CVP can directly send calls to CUCM (CUCM must have SIP trunk configured for CVP)

2. CVP can use SIP Proxy, send out calls for Agent label to SIP proxy server and SIP proxy server can send send it back to CUCM. (CUCM must have trunk to SIP Proxy)

3. CVP can send agent calls to Gateway and gateway sends it back to CUCM.(gateway should have dial-peer and CUCM should be configured with trunk for gateway)

there are numerous ways you can configure CVP to route outbound labels (VRU label, Agent Label etc):

1) using static routes (configured on each call server)

2) Using outbound Proxy (Blindly sending all calls to outbound proxy)

3) using SIP server group with either local or DNS srv lookup

4) Dialed number pattern which can use either sip server group or sip proxy or static ip to route outbound calls.

now you have to determine what's being use here?

the best way is to look at CVP logs and determine.

and yes if CVP is sending calls to agent through gateway, then only you need dial-peer on gateway for agent extension range, otherwise no its not required it CVP sending calls to CUCM directly or by SIP Proxy.

[iptuser55]

Thanks for your reply 

Question

The options to send the call to ccm are as you said but what determines which one does cvp use- dial peer on a gw,  dnp or something else? 

Orginally there was no dnp in cvp for the agents I'm testing and so the queue to skill group failed. 

I then added an agent whose dn was in  dnp and that worked so I thought this was issue,  solution.  So also change the agent partition to a new test one which was not in any css and it failed as I expected so I started to look for a sip trunk in ccm to investigate the inbound css but I could not locate it.  I then though how are dnp used,  was the agent call from icm to ccm via the potential gw? 

I added the dial peer for the agent and some lone has tested it but it failed - I'm out of the office at the moment.

What determines how cvp sends the call-up,  directly to ccm via dnp

Thanks  

[Chintan Gajjar]

using ops console and looking at different places you can determine what exactly CVP uses to send out calls to agent.

Your best bet is to look at the CVP logs for calls you generate and it will have all the information.

[iptuser55]

Just to let you know, I fixed the problem

Initially the call failed at the queue to skill set step. No call offered at finesse

In the PG logs, there is not actual error  except “couldn`t find client stack for device target string 7421031”

I then added the DNP pointing to CCM BUT did no add a SIP back to CVP to CUCM. The call was then offered to Finesse but in a Reserved state which I could not answer.

Looking through the PG log files, you then start to see  “ Is ExtConfiguredin ATR-Found the extension xxxxxx in a valid ATR range due to the DNP configured

After making a call , Finesse then showed as Reserved but could not answer the call which led me to think about partitions

I then allocated a known working agent to the skill group and it worked , I then changed the agent partition to another partition which resulted in the agent now failing which pointed me to a “sip” trunk.

Since the  CVP trunk to CCM does not “contain” CSS and partitions then it must be something else. I then checked the GW and added a Dial-peer to the CUCM which then the agent started to work

Recap

 DNP is required to CUCM so ICM, CVP can signal to agent in CUCM- DNP has return to originating device

There is not requirement to have a CUCM to SIP trunk

A Valid Dial-Peer to CUCM is required for the agents

I will be test if removing the “return to originating device changes the DNP set up and whether I need to add a SIP from CUCM to CVP

[Murali_DS]

Did u validate the RONA settings, I had a similar issue where agent will be in reserved state for a moment and moved to Notready state, check the RONA settings in CVP -> Dialed Number Pattern, Agent Desk Settings and Agent's Phone. It should have a at least 2 sec interval between the other.

Agent Desktop < CVP Invite Timeout < Cisco Unified Communications Manager CFW Example: 10 seconds < 12 secs < 20 seconds CFW

Thanks,

M