RE: H323 and Callmanager Issues

Also just had one other idea.  Do you have H.323 bound to the IP address lis
ted in CallManager?

I highly recommend creating a Loopback address and putting "h323-gateway voi
p bind srcaddr <IP address of interface>".  It's the only way to guarantee t
he router will be using the correct address to communicate to CallManager.

________________________________

From: cisco-voip-bounces@puck.nether.net on behalf of Walenta, Phil
Sent: Wed 9/14/2005 11:52 PM
To: Trey Howland
Cc: cisco-voip@puck.nether.net
Subject: RE: [cisco-voip] H323 and Callmanager Issues

Just curious here, in your CallManager H.323 gateway definition, does the IP
 address show up in a state of "unregistered"?  If so, try issuing a reset f
rom that CallManager page.

________________________________

From: cisco-voip-bounces@puck.nether.net on behalf of Trey Howland
Sent: Wed 9/14/2005 8:59 PM
To: Kevin Thorngren
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] H323 and Callmanager Issues

After some more digging, it seems to be a VRF issue.  Below is the
output of debug ip packet and debug h225 events.  I see some packets
sent out the wrong interface.  G0/1960 is in the global routing table.

Trey

002337: *Sep 15 01:45:04.880 UTC: Changing to new event: CONNECT
h323chan_chn_connect: connecting to 10.10.10.1:1720

002338: *Sep 15 01:45:04.880 UTC: h323chan_gw_conn: Created socket fd=4
002339: *Sep 15 01:45:04.880 UTC: IP: tableid=0, s=10.4.1.2 (local),
d=10.10.10.1 (GigabitEthernet0/0.1960), routed via FIB
002340: *Sep 15 01:45:04.880 UTC: h323chan_gw_conn: connect in progress
on fd=4h323chan_chn_connect: using fd=4, owner_data(ccb) 0x459C4798
changing from NONE state to CONNECTING state

002341: *Sep 15 01:45:04.884 UTC: IP: tableid=1, s=10.10.10.1
(GigabitEthernet0/0.1760), d=10.4.1.2 (GigabitEthernet0/0.1760), routed
via RIB
002342: *Sep 15 01:45:04.884 UTC: IP: s=10.10.10.1
(GigabitEthernet0/0.1760), d=10.4.1.2 (GigabitEthernet0/0.1760), len
44, rcvd 3
002343: *Sep 15 01:45:04.884 UTC: IP: tableid=1, s=10.4.1.2 (local),
d=10.10.10.1 (GigabitEthernet0/0.1760), routed via FIB
002344: *Sep 15 01:45:04.884 UTC: IP: s=10.4.1.2 (local), d=10.10.10.1
(GigabitEthernet0/0.1760), len 40, sending
002345: *Sep 15 01:45:06.880 UTC: IP: tableid=0, s=10.4.1.2 (local),
d=10.10.10.1 (GigabitEthernet0/0.1960), routed via FIB
002346: *Sep 15 01:45:06.880 UTC: IP: tableid=1, s=10.10.10.1
(GigabitEthernet0/0.1760), d=10.4.1.2 (GigabitEthernet0/0.1760), routed
via RIB
002347: *Sep 15 01:45:06.880 UTC: IP: s=10.10.10.1
(GigabitEthernet0/0.1760), d=10.4.1.2 (GigabitEthernet0/0.1760), len
44, rcvd 3
002348: *Sep 15 01:45:06.880 UTC: IP: tableid=1, s=10.4.1.2 (local),
d=10.10.10.1 (GigabitEthernet0/0.1760), routed via FIB
002349: *Sep 15 01:45:06.880 UTC: IP: s=10.4.1.2 (local), d=10.10.10.1
(GigabitEthernet0/0.1760), len 40, sending
002350: *Sep 15 01:45:07.880 UTC: h323chan_close: TCP connection from
fd=4 closed
002351: *Sep 15 01:45:07.880 UTC: Changing to new event: CONNECT
h323chan_chn_connect: connecting to 10.10.10.2:1720

002352: *Sep 15 01:45:07.880 UTC: h323chan_gw_conn: Created socket fd=4
002353: *Sep 15 01:45:07.880 UTC: IP: tableid=0, s=10.4.1.2 (local),
d=10.10.10.2 (GigabitEthernet0/0.1960), routed via FIB
002354: *Sep 15 01:45:07.884 UTC: h323chan_gw_conn: connect in progress
on fd=4h323chan_chn_connect: using fd=4, owner_data(ccb) 0x459C4798
changing from NONE state to CONNECTING state

002355: *Sep 15 01:45:07.884 UTC: IP: tableid=1, s=10.10.10.2
(GigabitEthernet0/0.1760), d=10.4.1.2 (GigabitEthernet0/0.1760), routed
via RIB
002356: *Sep 15 01:45:07.884 UTC: IP: s=10.10.10.2
(GigabitEthernet0/0.1760), d=10.4.1.2 (GigabitEthernet0/0.1760), len
44, rcvd 3
002357: *Sep 15 01:45:07.884 UTC: IP: tableid=1, s=10.4.1.2 (local),
d=10.10.10.2 (GigabitEthernet0/0.1760), routed via FIB
002358: *Sep 15 01:45:07.884 UTC: IP: s=10.4.1.2 (local), d=10.10.10.2
(GigabitEthernet0/0.1760), len 40, sending
002359: *Sep 15 01:45:09.884 UTC: IP: tableid=0, s=10.4.1.2 (local),
d=10.10.10.2 (GigabitEthernet0/0.1960), routed via FIB
002360: *Sep 15 01:45:09.884 UTC: IP: tableid=1, s=10.10.10.2
(GigabitEthernet0/0.1760), d=10.4.1.2 (GigabitEthernet0/0.1760), routed
via RIB
002361: *Sep 15 01:45:09.884 UTC: IP: s=10.10.10.2
(GigabitEthernet0/0.1760), d=10.4.1.2 (GigabitEthernet0/0.1760), len
44, rcvd 3
002362: *Sep 15 01:45:09.884 UTC: IP: tableid=1, s=10.4.1.2 (local),
d=10.10.10.2 (GigabitEthernet0/0.1760), routed via FIB
002363: *Sep 15 01:45:09.884 UTC: IP: s=10.4.1.2 (local), d=10.10.10.2
(GigabitEthernet0/0.1760), len 40, sending
002364: *Sep 15 01:45:10.884 UTC: h323chan_close: TCP connection from
fd=4 closed

On Sep 14, 2005, at 9:19 PM, Kevin Thorngren wrote:

> Not sure if being in a VRF would be an issue or not.  I have not
> configured this myself.  If the CCM has connectivity to 10.4.1.2 then
> I suspect it should work.  A packet capture of the GW might help
> determine if there is a TCP connectivity problem.  You might not see
> anything useful in the CCM trace if the problem is with creating the
> TCP connection.
>
> Not sure which version of CCM 4.1 you are running but if it is 4.1(3)
> then you might be running into a known issue with change notification.
>  If the nodes being pointed to by the dial peers don't receive change
> notification for the new CCMAdmin config changes then they won't know
> about the H.323 GW and will reject the TCP connection.   Restarting
> the CCM service is the workaround for this issue and the issue is
> resolved in 4.1(3)sr1.
>
> Kevin
> On Sep 14, 2005, at 8:17 PM, Trey Howland wrote:
> 
>
>
Georgia Institute of Technology     Atlanta, Georgia
Georgia Tech Research Institute  Voice (404)894-7134
Electronic Systems Laboratory      Fax (404)894-7080

Public Key ID: 0x894F4419
[7338 D848 8BEE FF6D 23D1  4355 2F6C DE0C 894F 4419]

 ________________________________________
_______
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

 ________________________________________
_______
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip