Take a look at http://www.cisco.com/en/US/tech/tk1077/technologies_tech_note09186a00800a8928.shtml
I don't know what they mean by "Is the ARQ for an IP-IP call" Not sure if they mean cube or not, but it doesn't seem to matter, the answer leads you to the same decision point regardless "outvia configured for destination zone?" This might answer your second question also in a later post. From: Nara Shikamaru [mailto:shikam...@kagadis.com] Sent: Thursday, September 17, 2009 10:41 AM To: Michael Ciarfello Cc: OSL Group Subject: Re: [OSL | CCIE_Voice] Vol 2 Mod 1 Q 4.2 - CUBE and Gatekeepers Another question, When creating the gatekeeper in this scenario, three zones are created - 1 for CUCM, 1 for CME, and 1 for CUBE. Part of the syntax for the CME zone indicates "outvia" for CME calls which means that any calls coming from the zone have to be passed to CUBE in zone VIA. Okay, makes sense. What's harder to understand is why the CUCM calls are not doing the same thing. It seems like CUBE is being bypassed in the case of the outgoing call to CME from CUCM. On Wed, Sep 16, 2009 at 8:57 AM, Michael Ciarfello <mciarfe...@iplogic.com<mailto:mciarfe...@iplogic.com>> wrote: Yes. Except the last statement. CUBE is doing........ Codec conversion. The GK has nothing to do with codec negotiation. And there is only one GK. From: Nara Shikamaru [mailto:shikam...@kagadis.com<mailto:shikam...@kagadis.com>] Sent: Wednesday, September 16, 2009 11:20 AM To: Michael Ciarfello Cc: OSL Group Subject: Re: [OSL | CCIE_Voice] Vol 2 Mod 1 Q 4.2 - CUBE and Gatekeepers Okay, I think understand the logic better now. The gatekeepers are used to centralize the dial plans and the SBC is used to demarc sites (summarizing). In the context of the V2 L1 question, each site is using gatekeepers to keep the dial plans between HQ and BR2 centralized, then CUBE is used to manage the traffic between the gatekeepers (right?) On Wed, Sep 16, 2009 at 12:11 AM, Michael Ciarfello <mciarfe...@iplogic.com<mailto:mciarfe...@iplogic.com>> wrote: Well, simply put to just mess with you. Make it difficult. Why in real life? If you are running an H323 network to multiple clusters, you want the GK to manage CAC and centralized dial-plan management. Or even smaller scale, how about a bunch of CCME routers. Instead of MANY dial-peers and trying to manage them when new sites are added or changed, etc. One dial-peer to the GK. Then maybe you are doing SIP trunk out that same router. (SIP in the cloud). Easier than managing a SIP connection at each remote site. If you have a need to use a SIP trunk to a SIP provider that's on another cluster, then we need CUBE. Protocol conversion and use of different codecs. Maybe some CCME sites didn't purchase a bunch of DSPs for transcoding so just send G711 over the WAN. Maybe some sites did and want to conserve BW over the WAN. So there's the need for codec and transcoding. I've never used CUBE/GK combo it in real life. So the above are just my understanding of how it could be used. Maybe someone has used it in real life and can share their design and reasons for using it. ________________________________ From: Nara Shikamaru [shikam...@kagadis.com<mailto:shikam...@kagadis.com>] Sent: Wednesday, September 16, 2009 1:55 AM To: Michael Ciarfello Cc: OSL Group Subject: Re: [OSL | CCIE_Voice] Vol 2 Mod 1 Q 4.2 - CUBE and Gatekeepers Volume 2 Lab 1 uses CUBE in conjunction with Gatekeepers, which is confusing. Okay, I kind understand that mechanically CUBE works the same way as an H323 gateway in that you send the traffic and if everything is set up correctly it works. Why are gatekeepers and gatekeeper-controlled trunks used as well? I don't understand why they would do it. On Tue, Sep 15, 2009 at 6:20 PM, Michael Ciarfello <mciarfe...@iplogic.com<mailto:mciarfe...@iplogic.com>> wrote: Answers in-line. Hopefully you can see the color. ________________________________ From: ccie_voice-boun...@onlinestudylist.com<mailto:ccie_voice-boun...@onlinestudylist.com> [ccie_voice-boun...@onlinestudylist.com<mailto:ccie_voice-boun...@onlinestudylist.com>] On Behalf Of Nara Shikamaru [shikam...@kagadis.com<mailto:shikam...@kagadis.com>] Sent: Tuesday, September 15, 2009 4:40 PM To: OSL Group Subject: [OSL | CCIE_Voice] Vol 2 Mod 1 Q 4.2 - CUBE and Gatekeepers My question is not so much about specifics as it is clarity, would like to know your opinion. I'm working through implementing CUBE/SBC in this question (which I'm new to.) As a Session Border Controller, the SBC allows the implementation of security and conversion of voip traffic between codecs. Correct. Mostly used to connect, say to a SIP provider (which connects to a public IP address most of the time) and translates it to your private addressing. You can also have a direct tunk from CCM to the SIP provider. You would want to make sure the SIP provider is properly VLANed or firewalled to do this. Besides the security concerns, you also lose the ability to look at debugs of calls on the router, forcing you to go through many MBs of CCM trace files. The router can filter a debug based on a number of parameters which makes it much easier to see what's going on. So you do CCM to a CUBE at your site and point a dial-peer to their CUBE (or SBC more generically if they are not using Cisco, but most SIP providers I've seen are using Cisco equipment.) This question also requires gatekeeper registration. My impression is that gatekeepers are needed to register to CUBE. The other way around for this question. The CUBE registers as an h323 gateway to the gatekeeper so you can do your protocol conversion. In a CCIE v2 workbook, they used GK/CUBE to translate to a SIP trunk to the BR2 site. And they were messing with codecs at the same time. You can use CUBE without a gatekeeper. The GK is in there for h323 centralized dial-plan management. You can trunk CCM to CUBE without GK. I've seen this done at a couple customers. All gateway objects in CCM were being CUBED to a router or set of routers then call was going out some local PRIs and/or a WAN connection to a PSTN in the cloud at the LEC. If I have two sites like HQ and BR2 and wanted to set up inter-site calling in its simplest terms, I COULD set up VoIP dial peers fort BR2 to HQ and an H323 gateway pointing from HQ to BR2, correct? Correct. As well as many other combinations. Your scenario would need CUBE for h323to h323 at HQ. You will see if you turn off allow-connection h323 to h323 the call would not go through. Is the call reaching CCM at some point in your scenario? Or a CCME at HQ and BR2? Lots of combinations. Now, if I need to transcode, again I can set up local transcoders at each site. I still don't need an SBC. I would probably need an SBC is I wanted to configure some form of call manageability? Can CUBE registration happen without gatekeeper configuration? See above and see if that answers this last set of questions. I'm a little confused to answer them directly. Some might not apply or you want want to re-word some of these last questions based on the explanations above. CUBE doesn't register anywhere. It's like throwing a football over a fence. if someone is there to catch it--good. If not, your call fails. No one knows or can see if someone is on the oher side of the fence until you throw that football.. Like H323 gateway. Now MGCP and GK, you know when someone is there or not. Good questions. Hard topic to understand if all you have as resources are Cisco documentation. -- -Shikamaru -- -Shikamaru -- -Shikamaru -- -Shikamaru
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
