[asterisk-users] [SOLVED] 404 Response to Invite - Should be 401

[Stuart Elvish]

Hi all,

This post is in case someone else has this problem.

The cause of the issue turned out to be one of the site technicians
having the same extension registering from his laptop as the ATA we
were testing. His laptop wasn't always connected to the voice network
and the soft-phone wasn't always on. Sometimes we were able to make
calls from the ATA we were testing and sometimes we would get the
problem described below.

Everything came to light when his soft-phone registered (throwing up a
non-voice network IP address) whilst I was watching the CLI and we
realised the problem...

Hope this helps someone.

---------- Forwarded message ----------
Date: 1 April 2012 23:42
Subject: 404 Response to Invite - Should be 401
To: Asterisk Users Mailing List - Non-Commercial Discussion
<asterisk-users at lists.digium.com>


Hi all,

I am currently testing a new version of firmware released by an ATA
vendor and I have come across a strange problem in 1.8.9.0.

Sometimes if I dial immediately after hanging up a previous call (we
used voicemail for our testing as it has "unlimited" capacity)
Asterisk will return a 404 code instead of doing the usual INVITE -
401 - INVITE sequence. The CLI says that the call failed because the
extension was not found in context 'default'. It appears from this (as
the ATA is correctly setup and normally make calls to a different
context) that Asterisk believes the extension is unauthenticated for
some calls and sending them straight to the guest (default) context.

What should I be looking for in the initial invite from the ATA which
will be triggering a 404? Is there something wrong in the SIP header /
body which would be triggering a "safety lock down" of the call? I
have tried to look at the invite packets but I can't see anything that
is incorrect.

On one occasion the sequence was INVITE - 401 - INVITE - 404 but most
commonly it is INVITE - 404.

We have also noticed that sometimes the ATA stops responding to
OPTIONS requests (qualify) whilst this issue is happening and there
may be some other registration issues. Some diagnostics have already
been completed but so far we haven't found anything which points us to
where the issue actually is. We assume it is an ATA related issue.

Any pointers and suggestions greatly appreciated.