CUSP interaction with CUBE CVP

Unanswered Question
Oct 8th, 2009

Hi,

I'm working on a design which will bring calls inbound SIP and deliver calls to UCCE (CVP) and CUCM. I've seen the configuration guide and power point preso from Cisco, but I'm wondering if anyone has done this in practice and could shed some light.

Calls are being delivered G.729, route to CVP at G.711, then route to the agent at G.729.

1) Do I really need a separate physical interface for each network I plan to route calls. i.e., one for service provider, external CUBE, internal CUBE, CVP and CUCM.

2) I'm aware of the limitation on CUBE where it cannot re-negotiate the codec mid-call. Thus, requiring the call to be double-transcoded before sending to an agent. Does anyone have any sample configs of how the call flow would work? I'm thinking that the RTP stream can be transcoded the first time on CUBE, but we need another DSP resource to transcode it for the agent. Thus requiring dial peers from CUBE 1 to the DSP resource (another IP to IP gateway) for the transcoding, then some other type of dial peer to route to the agent. Would that mean dialpeer to CUCM?

3) Any gotchas with the DNS load balancing?

4) Anybody done all the above with Nuance?

5) Can I have just one NME module to service all logical networks, or do I need one per network?

6) Is the licensing really calculated as requests per second or 'calls per second'? I know it doesn't care about the call once it's established, and in my scenario, one call would require 3 requests (in from SP, in from CUBE, in from CVP). So if my license is 100, does that mean I can really only process 33 calls per second? (I know the call won't be delivered to the agent within that one second of the incoming call, but just trying to get a handle on call capacity. -- I really think the limitation is not, and will never be, licensing. In fact it will be the limitation of transcoding. Even the CUBE can handle more calls than transcoding resources.

Any help would be great! Thanks!

Erin

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
mdury Wed, 10/28/2009 - 11:41

Erin,

Have you gotten any answers to your questions?

emikelso Wed, 10/28/2009 - 17:31

No responses but here are my thoughts.

1) Do I really need a separate physical interface for each network I plan to route calls. i.e., one for service provider, external CUBE, internal CUBE, CVP and CUCM.

Answer: I don't need separate physical interfaces or IP networks.

2) I'm aware of the limitation on CUBE where it cannot re-negotiate the codec mid-call. Thus, requiring the call to be double-transcoded before sending to an agent. Does anyone have any sample configs of how the call flow would work? I'm thinking that the RTP stream can be transcoded the first time on CUBE, but we need another DSP resource to transcode it for the agent. Thus requiring dial peers from CUBE 1 to the DSP resource (another IP to IP gateway) for the transcoding, then some other type of dial peer to route to the agent. Would that mean dialpeer to CUCM?

Answer: I have no idea about this one.

3) Any gotchas with the DNS load balancing?

Answer: No idea

4) Anybody done all the above with Nuance? Answer: no response

5) Can I have just one NME module to service all logical networks, or do I need one per network?

Answer: I can have just one module for all networks.

6) Is the licensing really calculated as requests per second or 'calls per second'? I know it doesn't care about the call once it's established, and in my scenario, one call would require 3 requests (in from SP, in from CUBE, in from CVP). So if my license is 100, does that mean I can really only process 33 calls per second? (I know the call won't be delivered to the agent within that one second of the incoming call, but just trying to get a handle on call capacity. -- I really think the limitation is not, and will never be, licensing. In fact it will be the limitation of transcoding. Even the CUBE can handle more calls than transcoding resources.

Answer: Cisco says it's call setups. I still think that means signalling messages, but who knows.

yshraybman Thu, 11/05/2009 - 13:20

Supposedly mid-call codec renegotiation will be supported in CUBE 1.5 sometime next year.

Actions

This Discussion