[cisco-voip] Intercluster Trunk

[Tanner Ezell]

Well, I'm an idiot :)
I started thinking about why one publisher would work and the other
wouldn't. Somehow on publisher 1, the default gateway was unset. I
configured it, rebooted. All is well.

I feel so stupid right now :)

On Fri, Apr 3, 2009 at 8:10 PM, Tanner Ezell <tanner.ezell at gmail.com> wrote:

> Okay guys here is what I've got so far.
> Two publishers, ICT works between the two (on my LAN)
> Publisher 2 to outside publisher, ICT Works.
> Publisher 1 to outside publisher, ICT fails. No idea why, the configuration
> is identical, except, on publisher 1 there DirSync service is running (ldap
> integration). Aside from that, configuration is similar/same (minus
> directory numbers being used).
>
> I checked my firewall (ASA 5505), its inspecting h225 properly, nothings
> blocking pub 1 from going out. I tried restarting the callmanager service on
> pub 1, no effect, reset the trunk, no effect, pointed the route pattern to
> pub 2, worked great.
>
> I've never run into this before, ICT's usually just worked. Can anyone
> provide some insight as to why this has failed? Anyone experience something
> similar?
>
> Thanks!
>
>
> On Fri, Apr 3, 2009 at 11:43 AM, Tanner Ezell <tanner.ezell at gmail.com>wrote:
>
>> Partitions and CSS are only setup the first publisher; They are able to
>> ping and as I mentioned calls work from publisher 1 to publisher 2 (full
>> audio both ways).
>>
>> On Fri, Apr 3, 2009 at 11:37 AM, Duy Nguyen <ccieid1ot at gmail.com> wrote:
>>
>>> Partitions, CSS?  Could they ping each other?
>>>
>>> On Fri, Apr 3, 2009 at 1:32 PM, Tanner Ezell <tanner.ezell at gmail.com>wrote:
>>>
>>>> As a test, I built another publisher on my LAN, created the ICT to the
>>>> other publisher on the LAN, built the Route Pattern, everything is setup,
>>>> reset the trunks and calls work.. from publisher 1(5XXX) to publisher 2
>>>> (6XXX). However calls from publisher 2 to publisher 1 ring busy.
>>>> Any ideas?
>>>>
>>>>
>>>> On Thu, Apr 2, 2009 at 8:30 PM, Tanner Ezell <tanner.ezell at gmail.com>wrote:
>>>>
>>>>> It is registered on both sides, I reset anyway and same result. Only
>>>>> thing I can think of is one is behind an ASA, could that be interfering? It
>>>>> is setup to inspect h323 and h225
>>>>>
>>>>> Sent via BlackBerry from T-Mobile
>>>>>
>>>>> ------------------------------
>>>>> *From*: "Ryan Ratliff"
>>>>> *Date*: Thu, 2 Apr 2009 23:23:15 -0400
>>>>> *To*: 'Tanner Ezell'<tanner.ezell at gmail.com>; 'VOIP Group'<
>>>>> cisco-voip at puck.nether.net>
>>>>> *Subject*: RE: [cisco-voip] Intercluster Trunk
>>>>>
>>>>>   Check to make sure your route list is registered.   If not try
>>>>> resetting it or pointing your route pattern directly at the trunk rather
>>>>> than using a RG/RL.
>>>>>
>>>>>
>>>>>
>>>>> -Ryan
>>>>>
>>>>>
>>>>>
>>>>> *From:* cisco-voip-bounces at puck.nether.net [mailto:
>>>>> cisco-voip-bounces at puck.nether.net] *On Behalf Of *Tanner Ezell
>>>>> *Sent:* Thursday, April 02, 2009 11:16 PM
>>>>> *To:* VOIP Group
>>>>> *Subject:* [cisco-voip] Intercluster Trunk
>>>>>
>>>>>
>>>>>
>>>>> Hey all, I'm using CUCM v7 in my lab and I'm having a hard time getting
>>>>> an ICT (non-gk) working between CUCM publishers. Assuming a virgin install,
>>>>> I created a trunk, set the ip of the other publisher. I created a route
>>>>> group containing the trunk, I created a route list containing the route
>>>>> group, and a route pattern pointing to the route list. When i attempt to
>>>>> dial the other side, i get fast busy and I see no call signaling from my
>>>>> call manager to the other publisher. Can anyone provide some insight on
>>>>> where to look? I'm out of ideas.
>>>>>
>>>>>
>>>>>
>>>>> Thanks all.
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> cisco-voip mailing list
>>>> 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/20090403/bb6e7284/attachment.html>