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. And see here for current known issues.

New Member

CVP WAN Deployment Model to avoid IVR and Queue message overhead over GMPLS

We have a UCCE environment in our premises which comprises  as below:

CVP 7.0(2) i.e two call server A and B. Each co-resident with VXML Server and Media Server.

CVP Ops Console

ICM 7.5 i.e. Two Roggers A and B

Two Voice Gateways 3945 each containing PVDM3-256 

CUCM 7.1.3 i.e. One Publisher and Two Subscribers

 

We have a new client from different country who wants to utilize our contact center services and they are intending to connect to us over a GMPLS link with 8MB bandwidth. The client has a green field site and will install two voice gateway at their end which are 3945 gateways again and each containing PVDM3-64 and PRI lines will be terminated on each voice gateway. SIP trunk is intended to be established from the client's site using the voice gateways to our Call Manager. 

Let's Call here the client's site as Site A and our site where we have UCCE environment as Site B

The requirement  is when the customers call the local number in client's country i.e. Site A, then those calls should be attended by the Agents on Site B through the Skill Group Queue. But each call needs to be served by IVR first. As the UCCE environment is only at Site B currently, so our problem is how we can avoid  overhead of media/IVR  and queue waiting message on the GMPLS link until the call is answered by Agent at site B.

One of the vendors suggest us to have a separate CVP environment on Site A to avoid the overhead of IVR and wiating message on GMPLS.

One fact we know, but not sure, as voice gateways on Site A will also have VXML GW/VRU (as 3945 is ingress and VXML GW), so the prompts will be cached in the voice gateway itself at Site A from the media servers at site B, so the media may not be travelling repeatedly from Site B to Site A. Is this understanding correct? 

Even if our understanding is correct, we came to know by reading few other forum discussions that the VXML documents will still be travelling from Site B to Site A because as VXML servers are only at Site B currently. And also the fact was mentioned on forums that the VXML document overhead is more than a media file itself. So is this really true that vxml documents will be travelling from B to A and will occupy more bandwidth as compare to media files?

 

Will also appreciate if you guys can give us any good suggestion what model should we adopt? We really want to avoid unnecessary costs until it becomes desperate need. Do we really require a separate CVP environment on Site A? Is there any other way except new CVP environment to avoid the overhead of IVR and waiting message?

 

 

Regards

1 ACCEPTED SOLUTION

Accepted Solutions

Let me try to answer your

Let me try to answer your question as much as i can:

1) so our problem is how we can avoid  overhead of media/IVR  and queue waiting message on the GMPLS link until the call is answered by Agent at site B.

There are multiple things which can help in reducing this traffic:

--> enable the caching on gateway, this will reduce the repeated medi fetch.(3945 does have a caching capacity ) or deploy media server local to VG, and configure these VGs to use the local media server instead of going over the WAN.
--> if you are concerned about the VXML messages, and if you have very high call volume which is expected to produce too many VXML Pages, and if you think that exceeds your bandwidth then you can install CVP local to Site. but in this case you have calculate the GED-125 traffic  flowing between CVP and VRU PG.

i strongly recommend you to go through SRND and calculate the bandwidth based on the call volume,The time each call spends in an IVR,Agent Transfer etc. 
please go through the CVP SRND, it has all the required information on how to calculate bandwidth for distributed deployments.

 

2) so the media may not be travelling repeatedly from Site B to Site A. Is this understanding correct?

Yes you are right, you can enable http client caching on 3945, this will cache the media files local to voice gateway till the expiration time.

3) So is this really true that vxml documents will be travelling from B to A and will occupy more bandwidth as compare to media files?

Notcompletely, VXML documents size will vary based on the type of node, please check the SRND for the same. 
Complex VXML application will recuire more VXML pages to transfer between CVP and VG. also it depends on number of prompts, for each prompt CVP will produce once VXML Page.

4)Will also appreciate if you guys can give us any good suggestion what model should we adopt?

calculate the bandwidth consuption, and check which model best suits you.
In my opinion the distributed model is good approach.

5) Is there any other way except new CVP environment to avoid the overhead of IVR and waiting message?

You can avoid some overhead by reducing root document size for VXML, caching media files local to VXML gateway. best thing is to get everything on paper and calculate the adequate bandwidth, if everything fits up you many not have to throw new CVP environment.
and if you plan to setup new environment, then you have to take care of bandwidth calculation for  (VOIP + GED 125 traffic).

9 REPLIES

Let me try to answer your

Let me try to answer your question as much as i can:

1) so our problem is how we can avoid  overhead of media/IVR  and queue waiting message on the GMPLS link until the call is answered by Agent at site B.

There are multiple things which can help in reducing this traffic:

--> enable the caching on gateway, this will reduce the repeated medi fetch.(3945 does have a caching capacity ) or deploy media server local to VG, and configure these VGs to use the local media server instead of going over the WAN.
--> if you are concerned about the VXML messages, and if you have very high call volume which is expected to produce too many VXML Pages, and if you think that exceeds your bandwidth then you can install CVP local to Site. but in this case you have calculate the GED-125 traffic  flowing between CVP and VRU PG.

i strongly recommend you to go through SRND and calculate the bandwidth based on the call volume,The time each call spends in an IVR,Agent Transfer etc. 
please go through the CVP SRND, it has all the required information on how to calculate bandwidth for distributed deployments.

 

2) so the media may not be travelling repeatedly from Site B to Site A. Is this understanding correct?

Yes you are right, you can enable http client caching on 3945, this will cache the media files local to voice gateway till the expiration time.

3) So is this really true that vxml documents will be travelling from B to A and will occupy more bandwidth as compare to media files?

Notcompletely, VXML documents size will vary based on the type of node, please check the SRND for the same. 
Complex VXML application will recuire more VXML pages to transfer between CVP and VG. also it depends on number of prompts, for each prompt CVP will produce once VXML Page.

4)Will also appreciate if you guys can give us any good suggestion what model should we adopt?

calculate the bandwidth consuption, and check which model best suits you.
In my opinion the distributed model is good approach.

5) Is there any other way except new CVP environment to avoid the overhead of IVR and waiting message?

You can avoid some overhead by reducing root document size for VXML, caching media files local to VXML gateway. best thing is to get everything on paper and calculate the adequate bandwidth, if everything fits up you many not have to throw new CVP environment.
and if you plan to setup new environment, then you have to take care of bandwidth calculation for  (VOIP + GED 125 traffic).

New Member

Hi Chantan,Thanks for the

Hi Chintan,

Thanks for the detail reply. Yes you are absolutely right i should read the CVP SRND. I had already read it partially. The document was also talking about edge queuing but it gave me the understanding of deploying distributed CVP, which requires a new CVP environment on the Site A and I was trying to find a way if there is any chance if I can avoid this cost. Can you confirm me that for edge queuing i require another CVP environment on Site A?

I also heard about queuing through TCL scripts, not sure what is that. Anyways, let me go through SRND completely, and will comment further on this thread again.

 

 

 

 

Hi, once again let me try to

Hi,

 

once again let me try to answer question from both of the above posts:

--> But I am wondering which component on Site A will facilitate the queuing of calls? Can 3945 without a CVP do the call queuing ?

My Answer: In CVP, Queuing on the edge means keeping RTP at the edge between VXML Gateway and Caller at the edge sites, so the RTP doesn't have to travel over the WAN to Center site for Queuing.

CVP will provide VXML instructions to edge site gateways(No Media flow), and the edge gateway will provide queuing treatment to caller using local VXML gateway functionality. this avoids flowing RTP over the WAN and call gets remained Queued at Edge site.

--> Can you confirm me that for edge queuing i require another CVP environment on Site A?

Answer: Now to Achieve this, you don't have to  introduce a new CVP environment, but you can use the existing beautiful functionality of CVP to queue the call at the edge. And perhaps you are using CVP 7.X below ones you can use:

1) CVP send to Originator configuration:

this configuration is useful in the cases where your deployment has VXML and Ingress gateway functionality co-resident/on Same gateway. In simple meaning, the same gateway will be used for VXML treatment where the call has arrived from PSTN.

if you will be using separate VXML gateway and voice gateway, then this configuration will not work.

2) CVP Sig Digits: By assuming that you will be using SIP as a call control protocol for CVP, CVP sig digits can help you queuing call at the edge sites by using some site code which will be used for prefix.

this functionality is helpful if you have site running separate VXML and Ingress Gateway, and calls coming from Ingress gateway to CVP will be queued to local site VXML gateway.

this requires some configuration effort, but its flexible in use.

--> the CVP on Site B can do the queuing on Site A for IVR treatment. But I am wondering which component on Site A will facilitate the queuing of calls? 

You have quite misunderstood the architecture of CVP, CVP is product and solution.

CVP relies on VXML gateways Voice Browser Functionality to prompt and collect data to customer by rendering the VXML documents sent by CVP call server/VXML server.

 

so basically queuing in CVP means, CVP keeps on saying VXML gateway to play some queuing music to caller until the agent becomes available.(This will be achieved by ICM or VXML scripting ). behind the scenes,  CVP is sending VXML pages to VXML gateway which instructs gateway to play some music, and when done ASk CVP once again for what to do further. This cycle keeps running until agent becomes available.

when Agents becomes available, CVP disconnects call from VXML gateway and ingress gateway and connects call between ingress gateway and Agent Phone.

 

HTH

 

regards

Chintan

New Member

Hi Chintan,

Hi Chintan, Thanks for the reply in detail again. With the help of the description you provided, I am now sure that we can achieve edge queuing without having another CVP on Site A. As per your suggestions in the first post, I am trying to do the bandwidth utilization calculation. As I am not expert, so I will paste it over here in this thread and would like to have your opinion on it. Thanks once again, for helping out. Regards,
New Member

Hi,the RTP will have to flow

Hi,

the RTP will have to flow across to Side B when calls are delivered to the agent, you have no escape there.

You can save some bandwidth at the call treatment time, and when calls are queued as the media will be streamed locally from side A.

New Member

Thanks Chintan and Gaurav.

Thanks Chintan and Gaurav. One more thing i wanted to know, as there are few methods defined in the CVP documents to achieve the edge queuing and one of those methods is "Send to Originator" instruction from CVP to voice gateway. Is this "Send to Originator" instruction only supported by CVP platform or is it a kind of standard request supported in SIP technology? The reason I am asking this question is that  i was wondering if we have any other VOIP system on Site B, let say Genesys and its SIP server, will Genesys be able to send the "Send to originator" Instruction to Voice Gateway to keep the call on edge?

 

 

Regards

 

"send to originator" is only

"send to originator" is only specific to CVP, CVP uses this setting to send the call back to originator for defined pattern. this configuration helps when you have Ingress and VXML gateway residing on same device.

 

in Genesys you have to figure out the similar configuration, it may be available or it may not.

 

regards

Chintan

New Member

Thank you to answer my query.

Thank you to answer my query. I really appreciate it.

New Member

Chintan, I was reading

Chintan, 

I was reading reading another post on the forum which discusses about the CVP's capability of "Send to Originator" to queue the call on the originator site. The link for the post is as follows:

 

https://supportforums.cisco.com/document/29711/hybrid-cvp-deployment-model-design

 

After reading the above post (Solution 1), it has given me understanding that by having 3945 Co Res VXML Gateway Router on Site A, the CVP on Site B can do the queuing on Site A for IVR treatment. But I am wondering which component on Site A will facilitate the queuing of calls? Can 3945 without a CVP do the call queuing ? Or have i misunderstood the post? One thing i would remind here, our Agents will only be at site B. So if my understanding is not wrong, then how the queue on Site A will connect customers to the Agents on Sites B?

 

Regards

160
Views
15
Helpful
9
Replies
CreatePlease login to create content