[cisco-voip] h323 to call manager inbound calls randomly complete

[Scott Irey]

Scott Irey
Network & Telecom Systems Engineer
Oakland University
Office: 248.370.2808
Mobile: 248.505.9827


-----Original Message-----
From: Scott Irey [mailto:irey at oakland.edu]
Sent: Thursday, March 18, 2010 2:16 PM
To: 'Peter Slow'
Cc: 'Nick Matthews'; 'cisco-voip at puck.nether.net'
Subject: RE: [cisco-voip] h323 to call manager inbound calls randomly
complete

I forgot to mention since this is a pre-production environment there is
only the one CUCM Publisher. Haven't brought up the CUCM subscribers yet.
Also the gateway on the interface is the a loopback address. We have the
interface set as an h323 gateway as well as the h323 src binding set as
well.

Scott Irey
Network & Telecom Systems Engineer
Oakland University
Office: 248.370.2808
Mobile: 248.505.9827


-----Original Message-----
From: Peter Slow [mailto:peter.slow at gmail.com]
Sent: Tuesday, March 16, 2010 8:22 PM
To: Scott Irey
Cc: Nick Matthews; cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] h323 to call manager inbound calls randomly
complete

Scott,
   debug ip tcp transact is the right thing to be looking at... Can we
see? Also, can you describe the network in between the gateway and the
CUCM server? what devices are in between and what does the network
look like?

   How many CUCM servers are in the cluster? Ideally, a timeout with
one or two would lead to a new TCP session being attempted with a
different callmanager server. if there are multiple callmanagers
involved and you see the same thing for that call  with the TCP
session establishment to multiple servers, that tells us one thing
(network) if it continually fails with one server but works with
another (and the two servers are in the same location) that might be
pointing at that particular CUCM. Either way, while we are figuring
out what the problem is, invlving multiple servers should help reduce
the actual impact of the issue. Use multiple dial-peers combined with
an h323 voice class and "h225 timeout tcp establish" to knock the
timers down to something that allows for quick failover to the next
dialpeer when the TCP session doesn't start up in a timely fashion.

-Pete

On Tue, Mar 16, 2010 at 1:55 PM, Scott Irey <irey at oakland.edu> wrote:
> Thanks! Funny you mentioned that as I did turn on debug ip tcp
> transactions and am able to see some tcp timeouts. Haven't had much time
> to go any further (not a production box) but seems to be something
there.
> Some negotiation of congestion window happens and then 3 tcp timeouts.
> Like I said, it's not every time.
>
> Strange.
>
> Scott Irey
> Network & Telecom Systems Engineer
> Oakland University
> Office: 248.370.2808
> Mobile: 248.505.9827
>
> -----Original Message-----
> From: matthn at gmail.com [mailto:matthn at gmail.com] On Behalf Of Nick
> Matthews
> Sent: Tuesday, March 16, 2010 1:47 PM
> To: Scott Irey
> Cc: cisco-voip at puck.nether.net
> Subject: Re: [cisco-voip] h323 to call manager inbound calls randomly
> complete
>
> Looking at this from a packet capture in a TCP level instead of odd
> H323 debugs will be much more helpful.
>
> -nick
>
> On Mon, Mar 15, 2010 at 10:12 AM, Scott Irey <irey at oakland.edu> wrote:
>> Hello,
>>
>>
>>
>> Having a problem with inbound calls from TDM completing h323 to cucm
> 7.1.
>> Seems to be fairly random, works once or twice, next call fails, cycle
>> repeats. Doing a debug CCH323 all, here is where a call fails and never
>> connects.
>>
>>
>>
>> ar 15 10:51:35.455: //-1/xxxxxxxxxxxx/H323/cch323_timer_dispatch:
>> Timer[CCH323_SOCK_WRITE_BLOCKED_TIMER] expired
>>
>> Mar 15 10:51:35.455:
>> //-1/xxxxxxxxxxxx/H323/h323_gw_sock_block_timer_expired: fd 2
>>
>> Mar 15 10:51:35.455:
>> //-1/xxxxxxxxxxxx/H323/h323_gw_start_sock_blocked_timer: fd 2
>>
>> Mar 15 10:51:35.455:
>> //-1/xxxxxxxxxxxx/H323/h323_gw_sock_block_timer_expired: Retry, fd=2
>>
>> Mar 15 10:51:35.555: //-1/xxxxxxxxxxxx/H323/cch323_timer_dispatch:
>> Timer[CCH323_SOCK_WRITE_BLOCKED_TIMER] expired
>>
>> Mar 15 10:51:35.555:
>> //-1/xxxxxxxxxxxx/H323/h323_gw_sock_block_timer_expired: fd 2
>>
>> Mar 15 10:51:35.555:
>> //-1/xxxxxxxxxxxx/H323/h323_gw_start_sock_blocked_timer: fd 2
>>
>> Mar 15 10:51:35.555:
>> //-1/xxxxxxxxxxxx/H323/h323_gw_sock_block_timer_expired: Retry, fd=2
>>
>> Mar 15 10:51:35.655: //-1/xxxxxxxxxxxx/H323/cch323_timer_dispatch:
>> Timer[CCH323_SOCK_WRITE_BLOCKED_TIMER] expired
>>
>> Mar 15 10:51:35.655:
>> //-1/xxxxxxxxxxxx/H323/h323_gw_sock_block_timer_expired: fd 2
>>
>> Mar 15 10:51:35.655:
>> //-1/xxxxxxxxxxxx/H323/h323_gw_start_sock_blocked_timer: fd 2
>>
>> Mar 15 10:51:35.655:
>> //-1/xxxxxxxxxxxx/H323/h323_gw_sock_block_timer_expired: Retry, fd=2
>>
>> Mar 15 10:51:35.755: //-1/xxxxxxxxxxxx/H323/cch323_timer_dispatch:
>> Timer[CCH323_SOCK_WRITE_BLOCKED_TIMER] expired
>>
>>
>>
>> Repeats this for a bit and then sends a disconnect. And I get operator
> from
>> the telco.
>>
>>
>>
>> Any one seen something like this before where some calls complete and
> some
>> don't?
>>
>> Scott Irey
>>
>> Network & Telecom Systems Engineer
>>
>> Oakland University
>>
>> Office: 248.370.2808
>>
>> Mobile: 248.505.9827
>>
>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>