CUBE Allow Connection statement

[balitewiczp]

I have two Cisco H323 GW interconnected with SIP.  My understanding is that the allow connection statement is defining endpoints, therefore, the allow connections would be sip-sip.  Is my thinking correct?

[paolo bevilacqua]

It is not really clear what your have, please explain in more detail.

[balitewiczp]

I have two gateways on two different CM clusters.  Each GW runs H323 for PSTN access.  There is a requirement to tie the two together so a shared receptionist could be used.  I would also need to implement media flow through, which I believe is the default.  B/c of the Ip addressing used, using the H323 interface that is bound for both CUBE and PSTN is not possible, therefore the idea is to use SIP for the CUBE function.

Since each respective GW will now be running H323  and SIP, I am asking what the "allow connections" command refers to in voice services voip.  The way I understand it, it refers to the endpoints, I would then use allow connections sip -sip.

Does this help clarify things?

[paolo bevilacqua]

balitewiczp wrote:
I have two gateways on two different CM clusters.  Each GW runs H323 for PSTN access.  There is a requirement to tie the two together so a shared receptionist could be used.

Just configure so that all calls go a the CM you designate. There is no need for CUBE to do what you want.

[balitewiczp]

The clusters are totally seperate, and are not connected.  Isnt one of the fucntions

of CUBE to be a demarcation point between two non connected clusters?

[Jonathan Schulenberg]

Allow connections refers to what VoIP dial-peer protocols are allowed for a VoIP-to-VoIP dial-peer call (ie both the incoming and outgoing dial-peers are voip, not pots). If you allow sip-to-sip, then an inbound dial-peer running sip can sucessfully connect through an outbound dial-peer running SIP. Directionality matters; sip-to-h323 is not the same as h323-to-sip.

[balitewiczp]

thank you very much for your response

[paolo bevilacqua]

The clusters are totally seperate, and are not connected.  Isnt one of the fucntions of CUBE to be a demarcation point between two non connected clusters?

CUBE is not needed to trunk two CMs. I do not see any advantage in your case, over a regular, direct connection.

[balitewiczp]

I already have gatekeeper controlled trunks one one of the clusters

.

Cluster A contains 3 global clusteres ( mentioned for the sake of clarity), all connected with gatekeeper trunks to each other.

Cluster B is totally seperate from all of this.

It is my understanding that you cannot have GK trunks and non GK trunks  on the same cluster.  We will not be using the GK to connect Cluster B

[paolo bevilacqua]

balitewiczp wrote:
I already have gatekeeper controlled trunks one one of the clusters
.
Cluster A contains 3 global clusteres ( mentioned for the sake of clarity), all connected with gatekeeper trunks to each other.
Cluster B is totally seperate from all of this.
It is my understanding that you cannot have GK trunks and non GK trunks  on the same cluster.  We will not be using the GK to connect Cluster B

I don't know of this limitation, however even if that is the case, I do not see how using CUBE would improve the situation.

[Steven Holl]

You can have GK controller and non-GK controller trunks on the same CM cluster, sure.

Add an ICT on each CM and you probably will be fine without adding any gateways/CUBEs.

The only think to be careful about is that when a call comes into CM, that it doesn't match the wrong inbound device (for capabilities) based on the source IP.  Hence, let's give this example:

CM A has a GK trunk

CM B has a GK trunk

CM A has an ICT pointing to C

CM C has an ICT pointing to A

CM C has a GK trunk

If were to place a call from CM A to CM C across the GK trunk, there is potential for the inbound h225 setup to match the inbound device of the CM A instance for the ICT instead of the GK trunk, since it will reverse-lookup the soruce IP of the h225 address and match the ICT device.  So it will pull the ICT's caps instead of the GK trunk's caps for that call, even though the call is actually going through the GK.  This may not pose to be a functional issue, but it should be a concern and carefully looked at during design.

If you make sure that all devices using the GK never have a way to talk to each-other via an ICT, (don't add GK-controlled devices to a CM as an ICT), then the devices calling across the GK trunk will not be listed in the CM database as an ICT, and you won't see this behavior.

Why not just use the GK trunk for these CM calls, though?  That would save some design headache regarding the aforementioned.