asterisk users - Apr 2007 - aastra phones with asterisk 1.2.17 - hangup after 20 seconds

Running asterisk 1.2.7 with latest zaptel on centos4.4. with Aastra 55i phones.
Local outbound calling works fine, but ATT requires clients enter 7 digit code
for long distance. All calls with 7 digit code are lost within 20 seconds of the
call. This is the message I?m getting:

Apr 19 12:38:16 WARNING[9615]: chan_sip.c:1228 retrans_pkt: Maximum retries
exceeded on transmission 68a2414694556e3ffbc4066f9fe6e109@10.1.1.190 for seqno
783509378 (Critical Response)
Apr 19 12:38:16 WARNING[9615]: chan_sip.c:1245 retrans_pkt: Hanging up call
68a2414694556e3ffbc4066f9fe6e109@10.1.1.190 - no reply to our critical packet.

The strange thing is that when I use an xten softphone this issue does not
occur. Is this a SIP signaling issue? Any help would be appreciated.  This issue
does not occurr with any other ip phone on our network. ONLY THE AASTRAs. any
ideas?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20070419/0d1f579c/attachment.htm

At 13:47 4/19/2007, Jeronimo Romero wrote:
>Running asterisk 1.2.7 with latest zaptel on centos4.4. with Aastra 
>55i phones. Local outbound calling works fine, but ATT requires 
>clients enter 7 digit code for long distance. All calls with 7 digit 
>code are lost within 20 seconds of the call. This is the message I'm
getting:
>
>Apr 19 12:38:16 WARNING[9615]: chan_sip.c:1228 retrans_pkt: Maximum 
>retries exceeded on transmission 
>68a2414694556e3ffbc4066f9fe6e109@10.1.1.190 for seqno 783509378 
>(Critical Response)
>Apr 19 12:38:16 WARNING[9615]: chan_sip.c:1245 retrans_pkt: Hanging 
>up call 68a2414694556e3ffbc4066f9fe6e109@10.1.1.190 - no reply to 
>our critical packet.
>
>The strange thing is that when I use an xten softphone this issue 
>does not occur. Is this a SIP signaling issue? Any help would be 
>appreciated.  This issue does not occurr with any other ip phone on 
>our network. ONLY THE AASTRAs. any ideas?
For the record, we fixed this on our 1.2.18 system by
recompiling per Brian Jones:

====================================================================http://lists.digium.com/pipermail/asterisk-users/2007-April/184875.html

The Cisco proxy was not replying to Asterisk with an ACK after *
sent an OK.

Since version 1.2.14, * was changed so that not receiving an ACK to an OK is
considered a FATAL error.

The specific change that causes this problem is in sip_answer() in
chan_sip.c:

res = transmit_response_with_sdp(p, "200 OK", &p->initreq, 2);

Changing the 2 to a 1 will probably fix it.  Note that this is NOT a bug in
* but improper implementations--either caused by latency, or a software bug
(not sending an ACK).  Perhaps it might be beneficial to have an option in
sip.conf to change how * handles not receiving an ACK?  I know... it's
someone else's problem, but might help those of us stuck with buggy
implementations in production environments. :)

Brian.
====================================================================
Calls using 4 digit account codes now do not drop after 20 seconds.