asterisk users - Aug 2010 - evil disconnect of call with cisco 1760

I have asterisk 1.6.2.11 talking to a cisco 1760 running
ipvoicek9-mz.124-25b.

whenever a call goes through the 1760's FXO or FXS (in or out) there is 
a 915 second maximum call time due to asterisk hanging up the call 
because of a "critical packet" being missed.

I read doc/sip-retransmit.txt and I don't see anything there that is 
helpful to my situation - the asterisk box is on the same subnet as the 
c1700; there are no nat/firewalls/sbcs in the middle.


at ~15:15 the asterisk console reads:
  WARNING[2492]: chan_sip.c:3778 retrans_pkt: Maximum retries exceeded 
on transmission CB674A02-B25C11DF-B6D5A08D-652FE73E at 10.9.1.9 for seqno 
102 (Critical Request) -- See doc/sip-retransmit.txt.
  WARNING[2492]: chan_sip.c:3805 retrans_pkt: Hanging up call 
CB674A02-B25C11DF-B6D5A08D-652FE73E at 10.9.1.9 - no reply to our critical 
packet (see doc/sip-retransmit.txt).


I have a full sip debug at: http://jeremy.kister.net/tmp/sip_debug/ast.txt

A running config of the c1760 is at 
http://jeremy.kister.net/tmp/sip_debug/c1760.txt

Important parts of sip.conf are at 
http://jeremy.kister.net/tmp/sip_debug/most_of_sip.conf


I have verified the same behavior with asterisk 1.6.1.12.


Ideas?


-- 

Jeremy Kister
http://jeremy.kister.net./

On 9/4/2010 1:31 AM, Jeremy Kister thought:
 > On 8/29/2010 3:25 AM, Jeremy Kister wrote:
>> whenever a call goes through the 1760's FXO or FXS (in or out)
there is
>> a 915 second maximum call time due to asterisk hanging up the call
>> because of a "critical packet" being missed.
 >
 > hmm, either no one has any clue/suggestions or they just don't care
 > about the issue - I better figure it out myself.  I wonder if it has
 > to do do with progress indicators on the 1760.


Thanks Jeremy, that was it!  I ended up putting:
  progress_ind progress enable 8
  progress_ind connect enable 8

on each dial-peer pots, and then:

  progress_ind setup enable 3
  progress_ind connect enable 8

on each dial-peer voip.

Problem seems solved.


-- 

Jeremy Kister
http://jeremy.kister.net./