Summary:ASTERISK-05493: SJphone "Awaiting acknowledgement" error after updating Asterisk to CVS-HEAD of September
Reporter:alexb (alexb)Labels:
Date Opened:2005-11-07 09:28:05.000-0600Date Closed:2011-06-07 14:10:04
Versions:Frequency of
Environment:Attachments:( 0) full_log-awaiting_ack
Description:Sometimes I can't answer calls with SJphone because of an "Awaiting acknowledgement" error.

The problem has come after I updated Asterisk from CVS HEAD of August to
HEAD of September. I had no other changes in my configuration, so I think it
must be related to something in Asterisk SIP handling. FYI, Asterisk is now updated to the latest CVS HEAD and the problem is still there.


The attached full log shows the following situation:

Incoming call from PSTN on chan_misdn
Group dial SIP/200&...&SIP/212, where extensions 200, 204, 205 and 212 are hardware phones and all other ext. are SJphone clients (v 1.60).

User at '202' wanted to answer the call, but its SJphone client displayed "Awaiting acknowledgement" and was still ringing.
User at '205' answered the call. User 202's SJphone finally stopped ringing and displayed "ACK Timeout" in a message box.

If needed, I can supply the tcpdump output file, too.
Comments:By: Mark Spencer (markster) 2005-11-07 10:59:00.000-0600

Can you please post a debug with an incoming call going to just the one sj phone and thus demonstrate the problem in a much easier to understand fashion?

By: alexb (alexb) 2005-11-08 04:45:49.000-0600

I tried several times to record an incoming call to just one SJphone but I've never been able to reproduce the problem, sorry. I think it could indeed be related to group dialing.

If it helps, I could send you the tcpdump log for the _same_ call, so you could filter and analyse the traffic with Ethereal or else. However, I'd prefer to send the file to a private e-mail address because I can't edit the packets to remove real phone numbers.

By: BJ Weschke (bweschke) 2005-11-11 08:24:38.000-0600

alexb: the problem here, I think, from the trace you've submitted is that 202 never seems to respond back to us to the original INVITE sent for this call and we end up retransmitting it. If 202 has gone to ringing state during this call, it's obviously receiving at least one of the 6 messages we're attempting to send to it. Then, it finally gets around to responding and it sends back multiple msgs to the same call (probably in response to the multiple retransmits we sent to it - even though it was with the same callid). Is the problem consistently reproducible with only the 202 peer? Is the CPU pinned maybe on the machine? Is there some kind of unique network situation going on? This doesn't "smell" like an Asterisk problem.

By: alexb (alexb) 2005-11-11 12:21:37.000-0600

Q: Is the problem consistently reproducible with only the 202 peer?
A: No, it has already happened at least once for each SJphone client. Unfortunately, it seems to be random, but with one exception: it seems to be more likely if we dial a group of extensions with Dial(SIP/XXX&...&SIP/XXX).

Q: Is the CPU pinned maybe on the machine?
A: No, the CPU isn't overloaded. The server runs just Asterisk.

Q: Is there some kind of unique network situation going on?
A: I don't think so. It happened in the following different situations:

1) Asterisk and clients in the same network. This is a basic scenario and there shouldn't be problems at all.
2) Asterisk in the DMZ (, clients in network.
3) Asterisk and all clients with their own public IP address each, that is open Internet, without issues regarding firewall, NAT, ...

I tested 1 and 2 by myself in my network environment. Scenario 3 was tested by our partner. Since we tested these scenarios in two different networks, I don't think it may be some kind of unique situation.

FYI, the Asterisk's version working before the update was 2005-08-02. Downgrading to that version makes everything working again. Maybe a bug in SJphone?

By: Kevin P. Fleming (kpfleming) 2005-12-12 19:45:56.000-0600

Suspending due to lack of activity... given that nobody else has reported this problem, it seems likely to be an SJPhone issue.