1) I think the hardware will support up to a maximum of 400 calls at a time per CUBE adding to a total of 800 calls. If I configure MTP for calls over WAN in CUBEs will it affect the number of calls? We will have a maximum of 400 simultanious calls at a time (loadbalanced between two) out of which 100 calls may need to use g729. How many MTP sessions required for 100 calls over wan in each CUBE?
It depends on if you need to require MTPs for every call or not. If not, the amount of MTPs depends on how often scenarios where you need an MTP occur (i.e. on a SIP trunk to CM, you'll need one when going to endpoints that aren't rtp-nte compatible, such as H323 endpoints, CTI ports, voicemail via SCCP). If you require an MTP, you need it for every call.
2) Can transcoder do the function of software, IOS and hardware MTP if we configure as shown below (even if we don't need xcoder for g729 conversion) or we should we configure xcoder and MTP seperate? what would be the better in terms of number of calls and resources utilized?
Will transcoder affect the number of calls in CUBEs.?
dspfarm profile 1 mtp_n_xcode
codec g711ulaw
codec g711alaw
codec g729r8
maximum sessions software 50
maximum sessions hardware 10
associate application sccp
sccp ccm group 1
associate profile 1 register mtp_xcode
telephony-service
sdspfarm units 1
sdspfarm tag 1 mtp_xcode
sdspfarm transcoder sessions 30
sdspfarm mtp sessions 60
exit.
You only can have one session type per profile. You can't do both hardware and software in the same profile. And your syntax is wrong--you don't name the profile in the dspfarm profile line. That is only for the transcode/mtp/conference keyword, and is how to specify the profile type. Hence, mtp_n_xcode is obviously not valid. HW MTP resources are typically only used for transrating (converting packetizations), which I doubt you need. IOS Software MTP gets you by in most scenarios, assuming you don't need to transcode for a codec mismatch. Transcoder should be in a separate MRG in the CUBE's MRGL, and below the MRG for the MTP, so that hte transcoder is only invoked when it needs to transcode. That ensures that the software MTP is used for other scenario. In scenarios where you have an MTP to be used, you need to pick a single codec to use on the trunk since CM isn't smart enough to pick a specific MTP for the codec it needs. Basically, if you have any scenarios where you need an MTP on CM, you have to ensure that you only use one codec on that trunk, and matches the codec for that MTP.
You don't need a software MTP registered to CUBE, ever, since in media-flow-through it's acting as a software MTP anyway. There are scenarios where you may need a transcoder registered to CUBE, if you have a coded mismatch there. That's the ideal way to support multiple codecs out your SIP trunk, actually; force a codec @ CUCM-CUBE and transcode if that doesn't match what CUBE-ITSP is.
3) Can we place software MTP in MRGL of the SIP trunk as well. Will this add any value? If MTP resources are required for a call which MTP will be used first - one in callmanager of one in CUBE with telephony service?
Yes, see above comment. You typically want software MTP resouces available on CUCM for scenarios where you need to pull DTMF out of the media stream and convert it to the signaling stream (a la rtp-nte on SIP to out-of-band on SCCP). If the codec to CUCM is g729, use an IOS software MTP.
4) We will have two more cubes in another location. How can we configure failover between the set of cubes in two locations. can we user gatekeeper for failover or Routelist? which is better.
It depends on the type of failover you're looking for. You'd need to be more descriptive in what scenarios you would have, and how you would want CUBE to behave (call preservation, supplementary services, etc.). The short answer is that CUBE does have some basic failover functionality, but signaling states are lost which is detrimental in scenarios where session refresh is required, so the call won't stay up past the timer pop.
GK is H.323. I'm not sure if you're talking SIP or H.323 on CUBE here, so I can't answer that.
I strongly recommend you talk to your Cisco account team regarding your CUBE design. It sounds like you have some fundamental confusions on some concepts, and you'll want to get them ironed out before implentation so that there are no suprises.
