asterisk users - Oct 2008 - Dropped Calls / Maximum Retries Exceeded / No Reply to Our Critical Packet

Hi All,

I've looked through the archives and tried several variations in Google, and
I haven't found anything on-point... So I'm hoping someone here may be
able to help this relative Asterisk neophyte shed some light on an issue:

I have a box running Asterisk 1.4.22 in our lab with several Cisco 7961G phones
and an AEX804E card (4 FXO, hardware echo cancellation).

The server and all phones are on the same subnet (10.2.0.x/255.255.255.0) of the
local LAN with no NAT, routing, firewall, etc., etc. between the server and the
phones.

Periodically I'm seeing calls placed from the 7961s through anything on the
PBX that requires digit entry (the Auto Attendant, Voicemail, etc.)
'randomly' drop; extension-to-extension calls extension-to-PSTN, and
PSTN-to-extension calls never have any issues whatsoever. Nor have I been able
to duplicate the issues hopping around auto attendants on an inbound PSTN call.

When the call drops, the phone still thinks that it is connected, but the audio
path is cut off and something similar to the following is dumped to the console

-- <SIP/1103-b71184e0> Playing 'vm-password' (language
'en')
[Oct 28 14:23:07] WARNING[9423]: chan_sip.c:1958 retrans_pkt: Maximum retries
exceeded on transmission 0016c82d-5455002d-2155dfac-8901da83 at 10.2.0.224 for
seqno 102 (Critical Response) -- See doc/sip-retransmit.txt.
[Oct 28 14:23:07] WARNING[9423]: chan_sip.c:1980 retrans_pkt: Hanging up call
0016c82d-5455002d-2155dfac-8901da83 at 10.2.0.224 - no reply to our critical
packet (see doc/sip-retransmit.txt).

All of the results Google has turned up, and the doc/sip-retransmit.txt file
point to problems with things in the middle of the path between the server and
the phone (NAT, firewall, "SIP middle box", proxy) that simply
don't exist in the configuration that we're using.

I suspect it's an issue with the way the Cisco phones are dealing with DTMF
to Asterisk or Asterisk dealing with the DTMF from Cisco but that's where I
go off into unknown territory. (FWIW, until the call drops everything works
fine, pressing a button triggers the desired action, and audio quality is
fantastic)

I've rolled the firmware on the phones up and down with no noticeable
change, and I also upgraded to Asterisk 1.4.22 version of Asterisk (I had been
running 1.4.21.2, and there are fewer dropped calls with .22 but it's still
way too often to be acceptable)

Any suggestions are greatly appreciated, but please be explicit... short of
editing the configuration files and "make install" my Asterisk
experience is rather limited.

Thanks in advance,

Lincoln

--
Lincoln King-Cliby, CTS
Applications Engineer
ControlWorks Consulting, LLC
http://www.thecontrolworks.com/

Lincoln King-Cliby wrote:
> Hi All,
> 
> I've looked through the archives and tried several variations in
Google, and I haven't found anything on-point... So I'm hoping someone
here may be able to help this relative Asterisk neophyte shed some light on an
issue:
> 
> I have a box running Asterisk 1.4.22 in our lab with several Cisco 7961G
phones and an AEX804E card (4 FXO, hardware echo cancellation).
> 
> The server and all phones are on the same subnet (10.2.0.x/255.255.255.0)
of the local LAN with no NAT, routing, firewall, etc., etc. between the server
and the phones.
> 
> Periodically I'm seeing calls placed from the 7961s through anything on
the PBX that requires digit entry (the Auto Attendant, Voicemail, etc.)
'randomly' drop; extension-to-extension calls extension-to-PSTN, and
PSTN-to-extension calls never have any issues whatsoever. Nor have I been able
to duplicate the issues hopping around auto attendants on an inbound PSTN call.
> 
> When the call drops, the phone still thinks that it is connected, but the
audio path is cut off and something similar to the following is dumped to the
console
> 
> -- <SIP/1103-b71184e0> Playing 'vm-password' (language
'en')
> [Oct 28 14:23:07] WARNING[9423]: chan_sip.c:1958 retrans_pkt: Maximum
retries exceeded on transmission 0016c82d-5455002d-2155dfac-8901da83 at
10.2.0.224 for seqno 102 (Critical Response) -- See doc/sip-retransmit.txt.
> [Oct 28 14:23:07] WARNING[9423]: chan_sip.c:1980 retrans_pkt: Hanging up
call 0016c82d-5455002d-2155dfac-8901da83 at 10.2.0.224 - no reply to our
critical packet (see doc/sip-retransmit.txt).
> 
> All of the results Google has turned up, and the doc/sip-retransmit.txt
file point to problems with things in the middle of the path between the server
and the phone (NAT, firewall, "SIP middle box", proxy) that simply
don't exist in the configuration that we're using.
> 
> I suspect it's an issue with the way the Cisco phones are dealing with
DTMF to Asterisk or Asterisk dealing with the DTMF from Cisco but that's
where I go off into unknown territory. (FWIW, until the call drops everything
works fine, pressing a button triggers the desired action, and audio quality is
fantastic)
> 
> I've rolled the firmware on the phones up and down with no noticeable
change, and I also upgraded to Asterisk 1.4.22 version of Asterisk (I had been
running 1.4.21.2, and there are fewer dropped calls with .22 but it's still
way too often to be acceptable)
> 
> Any suggestions are greatly appreciated, but please be explicit... short of
editing the configuration files and "make install" my Asterisk
experience is rather limited.
> 
> Thanks in advance,
> 
> Lincoln
It's hard to diagnose a problem like this without a full SIP trace, but
given
the problem you are describing, it looks like Asterisk is sending a SIP INVITE 
that is not being replied to with a 200 OK. It wasn't clear in the scenario
you
presented why Asterisk would be sending an INVITE out anywhere though, so
I'm
not sure where this is originating. Is Asterisk dialing out to another box which
contains the voicemail and auto-attendant services? If so, and if the box which 
provides these services is another Asterisk server, be sure that the second 
Asterisk server has an Answer in the dialplan for these calls.

By the way, to see a SIP trace inside Asterisk, you can issue the command
"sip
set debug" in the CLI. Then all SIP messages will be written anywhere where
you
are logging verbose messages.

Mark Michelson

Lincoln King-Cliby <lincoln at controlworks.com> writes:
> Periodically I'm seeing calls placed from the 7961s through anything
> on the PBX that requires digit entry (the Auto Attendant, Voicemail,
> etc.) 'randomly' drop; extension-to-extension calls
> extension-to-PSTN, and PSTN-to-extension calls never have any issues
> whatsoever. Nor have I been able to duplicate the issues hopping
> around auto attendants on an inbound PSTN call.
I am not sure this is relevant in the 1.4.x versions, but here goes
anyway:

In Asterisk 1.2.x it could sometimes happen that Asterisk believed the
path to a server was so good, that it would only allow 1 ms for
answers to be received. It would do all its retransmissions in less
than 200ms, and then it would complain about no reply to critical
packet.

Anyway, you can adjust the minimum timer with the configuration option
t1min in sip.conf. I would recommend setting it to at least 100 (it is
in ms) and perhaps 500 would help for you.

It is also highly possible that your issue is completely different.


/Benny