[cisco-voip] FW: CUCM Route List

[Mark Marquez]

I guess I wonder why the H.323 GW would send an appropriate response once(“temporary failure) and then not on subsequent calls (Unallocated/Unassigned Number).  I would expect the unallocated/unassigned cause code if I sent the wrong digits or length of digits.    The “temporary failure”   cause code makes sense because the T1 is down.

I agree with you that switching the order of the RG’s fixes the issue but the GW’s are not interchangeable.  Each GW is located at different sites.


From: george.hendrix at l-3com.com [mailto:george.hendrix at l-3com.com]
Sent: Wednesday, November 18, 2009 5:02 PM
To: Mark Marquez; cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] FW: CUCM Route List

Of course if the devices are totally interchangable with the same # of ports you can put the mgcp gw as your primary and since it registers with cucm, cucm will know if it is down.

Bill

________________________________
From: Hendrix, George (Bill) @ ITS
To: 'MMarquez at goldsys.com' <MMarquez at goldsys.com>; 'cisco-voip at puck.nether.net' <cisco-voip at puck.nether.net>
Sent: Wed Nov 18 18:56:17 2009
Subject: Re: [cisco-voip] FW: CUCM Route List
You are seeing this because the T1 status on the h.323 gw isn't known to cucm. I believe what you would need to do is setup dial peers between the mgcp gw and the h.323 gw. Then on the h.323 gw put a higher preference on the T1 with the dial peer to the mgcp gw next.

Bill

________________________________
From: cisco-voip-bounces at puck.nether.net <cisco-voip-bounces at puck.nether.net>
To: cisco-voip at puck.nether.net <cisco-voip at puck.nether.net>
Sent: Wed Nov 18 16:29:20 2009
Subject: [cisco-voip] FW: CUCM Route List
Here is some supplemental information regarding my previous email.  Here is a summary of the problem.

RouteList-1
   H323-HW-RG
  MGCP-GW-RG

I make a call that uses Route List (RL-1).  The first call is successful call via the H323-HW-RG.  I then disconnect the T1 cable to the H323 GW (creating a failover scenario) and my second call fails over successfully to the MGCP-GW-RG.  I make a third call, which again uses MGCP-GW-RG and the call fails.  All other subsequent calls also fail.

I ran a CCM trace and I see that on the second call attempt (first screenshot below) the H323 GW (10.10.32.2) sends back a H.225 RELEASE_COMP message with Cause i = 0x08E089 – Temporary Failure.  CUCM responds to this cause code by sending an MGCP CRCX message to the failover GW (10.10.32.1) thereby resulting in a successful call.


In the second screenshot where I made the third failed call attempt you’ll notice that the H.323 GW also sends a RELEASE_COMP message but it has a different cause code Cause I = 0x080081 – Unallocated/Unassigned Number.  As a result of this cause code CUCM does not send the MGCP CRCX message to the failover MGCP GW and the call ultimately fails.    Any ideas on how to modify this behavior?



[cid:image001.png at 01CA6871.38236F80]


[cid:image002.png at 01CA6871.38236F80]





From: Mark Marquez
Sent: Monday, November 16, 2009 4:42 PM
To: 'cisco-voip at puck.nether.net'
Subject: CUCM Route List

Are there any special rules regarding H.323 and MGCP gateways configured within the same CUCM Route List.  I have a route list with two route groups.  RG1 has the H.323 GW.  RG2 has the MGCP GW.

RL-1
                RG1 (H.323)
                RG2  (MGCP)

In the above configuration, failover to the MGCP GW doesn’t work.

RL-1
                RG2 (MGCP)
                RG1 (H.323)

I modify the Route List to include RG2 and then RG1 (as illustrated above) and failover works as expected.  FYI, I cause a failover by unplugging the T1 cable from the controller.

I also tested just using RG1 or RG2 within RL-1 and calls complete successfully.  Any help is appreciated.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20091119/c74d81d6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 101513 bytes
Desc: image001.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20091119/c74d81d6/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 99410 bytes
Desc: image002.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20091119/c74d81d6/attachment-0001.png>