[cisco-voip] creating vs routing over ICTs

[Wes Sisk]

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).

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.)

When CM receives an h225 session on 1720 it has to lookup the source IP 
address to identify the proper treatment (CSS, etc.)

Some of this is discussed here:
http://www.cisco.com/en/US/docs/voice_ip_comm/cust_contact/contact_center/customer_voice_portal/srnd/3_1/vp31surv.html#wp1045036
 

/Wes


Carter, Bill wrote:
> 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)?
>
> -Bill
>
> On Dec 1, 2010, at 4:40 PM, "Wes Sisk" <wsisk at cisco.com 
> <mailto:wsisk at cisco.com>> wrote:
>
>> Yes.
>>
>> 2 clusters::
>> c1s1-s6
>> s2s1-s6
>>
>>
>> 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.
>>
>> 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. 
>>
>> 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.
>>
>> /Wes
>>
>> Lelio Fulgenzi wrote:
>>> It's been a while, so thought I'd ask the list for some comments.
>>>
>>> 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:
>>>
>>> http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_tech_note09186a0080094729.shtml
>>>
>>> Because we have more than three subscribers in our clusters, we'll 
>>> have two ICTs on each cluster to ensure the full mesh.
>>>
>>> However, I'm pretty sure you only have to route calls over one of them.
>>>
>>>
>>>
>>> ---
>>> Lelio Fulgenzi, B.A.
>>> Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1
>>> (519) 824-4120 x56354 (519) 767-1060 FAX (JNHN)
>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> Cooking with unix is easy. You just sed it and forget it.
>>> Â Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â - LFJ (with apologies 
>>> to Mr. Popeil)
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net <mailto:cisco-voip at puck.nether.net>
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>   
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net <mailto:cisco-voip at puck.nether.net>
>> https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20101202/414fc838/attachment.html>