[Asterisk-Users] Working SPA 841s now return 404 Not Found for INVITES and OPTION packets from *

[Johnathan Corgan]

I don't know what's changed, but four SPA841s and a SPA3000 are no
longer answering when they get an inbound call from *.

This has been a working configuration for weeks. I *have* been fiddling
with the server config; however, the configuration is under version
control and I've reverted everything to exactly how it was when the
server was working. Doesn't fix it. I reset one of the SPA841s to
factory defaults and reconfigured, still has the problem.

Outbound calls from the SPA841s through the * server work fine.

How do I figure out what the SPAs are unhappy enough about to return
404? Below is a representative SIP DEBUG trace for a call; the OPTION
packet sent due to qualify=yes has the same response.

-Johnathan

Reliably Transmitting (no NAT) to 192.168.1.30:5060:
INVITE sip:192.168.1.30 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.2:5060;branch=z9hG4bK4b487795;rport
From: "asterisk" <sip:aste...@192.168.1.2>;tag=as24a55bd8
To: <sip:192.168.1.30>
Contact: <sip:aste...@192.168.1.2>
Call-ID: 571b9daf5b03610a...@192.168.1.2
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Max-Forwards: 70
Date: Sat, 11 Feb 2006 00:25:46 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Content-Type: application/sdp
Content-Length: 210

v=0
o=root 703 703 IN IP4 192.168.1.2
s=session
c=IN IP4 192.168.1.2
t=0 0
m=audio 19942 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -

---
-- Called jcorgan-desk
diamond*CLI>
<-- SIP read from 192.168.1.30:5060:
SIP/2.0 404 Not Found
To: <sip:192.168.1.30>;tag=cb1ee3725d25570ei0
From: "asterisk" <sip:aste...@192.168.1.2>;tag=as24a55bd8
Call-ID: 571b9daf5b03610a...@192.168.1.2
CSeq: 102 INVITE
Via: SIP/2.0/UDP 192.168.1.2:5060;branch=z9hG4bK4b487795
Server: Sipura/SPA841-3.1.1(a)
Content-Length: 0

_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

Asterisk-Users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users

[Andres]

Johnathan Corgan wrote:

>I don't know what's changed, but four SPA841s and a SPA3000 are no
>longer answering when they get an inbound call from *.
>
>This has been a working configuration for weeks. I *have* been fiddling
>with the server config; however, the configuration is under version
>control and I've reverted everything to exactly how it was when the
>server was working. Doesn't fix it. I reset one of the SPA841s to
>factory defaults and reconfigured, still has the problem.
>
>Outbound calls from the SPA841s through the * server work fine.
>
>How do I figure out what the SPAs are unhappy enough about to return
>404? Below is a representative SIP DEBUG trace for a call; the OPTION
>packet sent due to qualify=yes has the same response.
>
>-Johnathan
>
>
>Reliably Transmitting (no NAT) to 192.168.1.30:5060:
>INVITE sip:192.168.1.30 SIP/2.0
>Via: SIP/2.0/UDP 192.168.1.2:5060;branch=z9hG4bK4b487795;rport
>From: "asterisk" <sip:aste...@192.168.1.2>;tag=as24a55bd8
>To: <sip:192.168.1.30>
>
>

There is no username in the above "To" header. Check your DIAL command
because something is wrong here. Thats why you get a 404. The SPA
can't match the username.

>Contact: <sip:aste...@192.168.1.2>
>Call-ID: 571b9daf5b03610a...@192.168.1.2
>CSeq: 102 INVITE
>User-Agent: Asterisk PBX
>Max-Forwards: 70
>Date: Sat, 11 Feb 2006 00:25:46 GMT
>Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
>Content-Type: application/sdp
>Content-Length: 210
>
>v=0
>o=root 703 703 IN IP4 192.168.1.2
>s=session
>c=IN IP4 192.168.1.2
>t=0 0
>m=audio 19942 RTP/AVP 0 101
>a=rtpmap:0 PCMU/8000
>a=rtpmap:101 telephone-event/8000
>a=fmtp:101 0-16
>a=silenceSupp:off - - - -
>
>
>
>
>

--
Andres

[Johnathan Corgan]

Andres wrote:

> There is no username in the above "To" header. Check your DIAL command
> because something is wrong here. Thats why you get a 404. The SPA
> can't match the username.

Yes. I had not reverted to an early enough commit on the configuration
files and the usernames were still missing in sip.conf.

Thanks.

-Johnathan