<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
When CM registers with GK it registers only the nodes that in the CM
group of the trunk device.  CM advertises an ephemeral port rather than
the standard h225 port (1720).<br>
<br>
This means devices ARQ the GK, GK returns one of server1:port1,
server2:port2,server3:port3. When CM receives an h225 TCP session on
portN CM knows that calls is from GK so treats the call with the
properties configured for the GK device (CSS, etc.)<br>
<br>
When CM receives an h225 session on 1720 it has to lookup the source IP
address to identify the proper treatment (CSS, etc.)<br>
<br>
Some of this is discussed here:<br>
<a class="moz-txt-link-freetext" href="http://www.cisco.com/en/US/docs/voice_ip_comm/cust_contact/contact_center/customer_voice_portal/srnd/3_1/vp31surv.html#wp1045036">http://www.cisco.com/en/US/docs/voice_ip_comm/cust_contact/contact_center/customer_voice_portal/srnd/3_1/vp31surv.html#wp1045036</a><br>
<div style="display: inline;"> </div>
<br>
/Wes<br>
<br>
<br>
Carter, Bill wrote:
<blockquote
 style="border: medium none  ! important; padding-left: 0px ! important; padding-right: 0px ! important; margin-left: 0px ! important; margin-right: 0px ! important;"
 cite="mid:4CAE7968-04A4-4555-B43C-C230113CE147@sentinel.com"
 type="cite">
  <div>Wes, what is different from the new method vs. creating an ICT
on each cluster pointing to a Gatekeeper (pair of GK in hsrp or GK and
alt GK)?<br>
  <br>
  </div>
  <div>-Bill</div>
  <div><br>
On Dec 1, 2010, at 4:40 PM, "Wes Sisk" <<a moz-do-not-send="true"
 href="mailto:wsisk@cisco.com">wsisk@cisco.com</a>> wrote:<br>
  <br>
  </div>
  <blockquote
 style="border: medium none  ! important; padding-left: 0px ! important; padding-right: 0px ! important; margin-left: 0px ! important; margin-right: 0px ! important;"
 type="cite">
    <div>Yes.<br>
    <br>
2 clusters::<br>
c1s1-s6<br>
s2s1-s6<br>
    <br>
    <br>
you could just create 1 ICT on each cluster.  Point to the first 3
servers of the remote cluster.  Use a device pool that uses a cmgroup
that includes the first 3 servers of the local cluster.<br>
    <br>
This will work in all "recent versions" (i'm going to say >=6.x,
roughly) of CUCM where we changed h225d to only run on nodes in the
device pool.  <br>
    <br>
In older versions (4.x) creating the ICT created h225d on all nodes in
cluster1.  this allowed any node in cluster1 to initiate an h225 tcp
session to clsuter2.  if cluster2 received an h225 session from c1s4
and that was not configured as an ICT remote destination then cluster2
would reject the session and call would fail.<br>
    <br>
/Wes<br>
    <br>
Lelio Fulgenzi wrote:
    <blockquote
 style="border: medium none  ! important; padding-left: 0px ! important; padding-right: 0px ! important; margin-left: 0px ! important; margin-right: 0px ! important;"
 cite="mid:60090578.768073.1291236509667.JavaMail.root@simcoe.cs.uoguelph.ca"
 type="cite">
      <style type="text/css">p { margin: 0; }</style>
      <div
 style="font-family: Verdana; font-size: 10pt; color: rgb(0, 0, 0);">It's
been a while, so thought I'd ask the list for some comments.<br>
      <br>
As far as I remember, it's important to create intercluster trunks in a
full mesh design, so that each subscriber is represented in the ICT of
the other cluster. This is also explained here:<br>
      <br>
      <a moz-do-not-send="true"
 href="http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_tech_note09186a0080094729.shtml">http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_tech_note09186a0080094729.shtml</a><br>
      <br>
Because we have more than three subscribers in our clusters, we'll have
two ICTs on each cluster to ensure the full mesh.<br>
      <br>
However, I'm pretty sure you only have to route calls over one of them.<br>
      <br>
      <br>
      <span><br>
      <span name="x"></span>---<br>
Lelio Fulgenzi, B.A.<br>
Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1<br>
(519) 824-4120 x56354 (519) 767-1060 FAX (JNHN)<br>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<br>
Cooking with unix is easy. You just sed it and forget it. <br>
   Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â - LFJ (with apologies to
Mr. Popeil)<br>
      <span name="x"></span><br>
      </span><br>
      </div>
      <pre wrap=""><hr size="4" width="90%">
_______________________________________________
cisco-voip mailing list
<a moz-do-not-send="true" href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a>
<a moz-do-not-send="true"
 href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</a>
  </pre>
    </blockquote>
    </div>
  </blockquote>
  <blockquote
 style="border: medium none  ! important; padding-left: 0px ! important; padding-right: 0px ! important; margin-left: 0px ! important; margin-right: 0px ! important;"
 type="cite">
    <div><span>_______________________________________________</span><br>
    <span>cisco-voip mailing list</span><br>
    <span><a moz-do-not-send="true"
 href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a></span><br>
    <span><a moz-do-not-send="true"
 href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</a></span><br>
    </div>
  </blockquote>
</blockquote>
</body>
</html>