Need SIP 404 when no DID Exists on Asterisk

I need to share my VOIP vendor account with multiple devices, one of which is Asterisk. To do this, I need Asterisk to not answer (no message or fast busy) and to return a SIP 404 which says that the DID does not exist in the Asterisk domain. This will give the device which does host the DID a chance to answer.

I also notice that SIP termination messages are not noted in the log. I think it would be useful to include them.

What is required to configure Asterisk to respond with a SIP 404?

Thanks.

To see the SIP messages, use the cli command: sip set debug on. This will generate a lot of output!

To send a 404 response, use the equivalent ISDN cause code (try 1) as a parameter to the hangup application. You can find the actual codes in a switch in chan_sip.c, but I think that codes complies with the RFC. I’m fairly sure that 1 is correct for 404, although 404 is not the correct response in terms of the scenario you are actually describing.

(If the ITSP has a good system, they will be calling both numbers in parallel, so no response would also work, but I think there is a user not present response that would be more appropriate.)

Thank you for the tips. I believe we tried the Hangup(1) but I will revisit it. The vendor says he needs a 404.

Unfortunately, no response is also hard to come by as it seems Asterisk tends to respond with audio messages. For example, congestion results in fast busy but the call is answered by asterisk who plays the fast busy.

Which file will the debug info end up in?

Asterisk will not answer a call unless you do something that tells it to do so, or set an option for in band progress.

Many dialplans, incorrectly start with an explicit call to Answer.

Asterisk will never generate a voice announcement over SIP unless the dialplan explicitly tells it to do so. If your system is doing so, I suspect you are using someone else’s dialplan, most likely one provide by a GUI. This is not the right forum for how to configure an Asterisk GUI. Those are mainly on other web sites.

Once answered, it is too late to send 404.

I think the basic SIP trace information goes to the console by default. You can set the destinations for debug output in logger.conf. Normally you would uncomment the full log entry if doing serious debugging.

You would generally want verbose at least 3. You don’t need core debug set for sip traces for serious debugging you would want both it, and verbose set to at least 5.

Here is the table of SIP codes:

ISUP Cause value SIP response


1 unallocated number 404 Not Found
2 no route to network 404 Not found
3 no route to destination 404 Not found
16 normal call clearing — (*)
17 user busy 486 Busy here
18 no user responding 408 Request Timeout
19 no answer from the user 480 Temporarily unavailable
20 subscriber absent 480 Temporarily unavailable
21 call rejected 403 Forbidden (+)
22 number changed (w/o diagnostic) 410 Gone
22 number changed (w/ diagnostic) 301 Moved Permanently
23 redirection to new destination 410 Gone
26 non-selected user clearing 404 Not Found (=)
27 destination out of order 502 Bad Gateway
28 address incomplete 484 Address incomplete
29 facility rejected 501 Not implemented
31 normal unspecified 480 Temporarily unavailable

Problem seems to be that not answering is not creating a SIP 404 but I am told it is sending a 603 which appears not to be correct.

I understand that SIP 603 says “number not here and I can assure you it is mot anywhere else, so stop looking”. Asterisk can not actually be sure it is nowhere else so SIP 404 apears to be the correct answer.

I would like it very much if someone could confirm what I believe is true.

603 is declined, and is only used for specific error conditions. You need to do the full sip set debug on, verbose 5, debug 5 debugging on a call.

Here is log from DID sent to "TERMINATE CALL/HUNGUP"
Notice the SIP 603

<------------->
[2013-04-08 18:53:03] VERBOSE[4430] chan_sip.c: — (17 headers 11 lines) —
[2013-04-08 18:53:03] VERBOSE[4430] chan_sip.c: Sending to 216.115.69.144:5060 (NAT)
[2013-04-08 18:53:03] VERBOSE[4430] chan_sip.c: Using INVITE request as basis request - 1342726370_14996747@4.55.17.35
[2013-04-08 18:53:03] VERBOSE[4430] chan_sip.c: Found peer ‘FlowRoute_LV’ for ‘+12039796621’ from 216.115.69.144:5060
[2013-04-08 18:53:03] VERBOSE[4430] chan_sip.c: Found RTP audio format 0
[2013-04-08 18:53:03] VERBOSE[4430] chan_sip.c: Found RTP audio format 18
[2013-04-08 18:53:03] VERBOSE[4430] chan_sip.c: Found RTP audio format 101
[2013-04-08 18:53:03] VERBOSE[4430] chan_sip.c: Found audio description format G729 for ID 18
[2013-04-08 18:53:03] VERBOSE[4430] chan_sip.c: Found audio description format telephone-event for ID 101
[2013-04-08 18:53:03] VERBOSE[4430] chan_sip.c: Capabilities: us - (ulaw|g729), peer - audio=(ulaw|g729)/video=(nothing)/text=(nothing), combined - (ulaw|g729)
[2013-04-08 18:53:03] VERBOSE[4430] chan_sip.c: Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|)
[2013-04-08 18:53:03] VERBOSE[4430] chan_sip.c: Peer audio RTP is at port 4.55.17.2:5480
[2013-04-08 18:53:03] VERBOSE[4430] chan_sip.c: Looking for 12036354616 in from-trunk (domain 67.86.3.196)
[2013-04-08 18:53:03] VERBOSE[4430] chan_sip.c: list_route: hop: sip:216.115.69.144;lr
[2013-04-08 18:53:03] VERBOSE[4430] chan_sip.c: list_route: hop: sip:216.115.69.132;lr
[2013-04-08 18:53:03] VERBOSE[4430] chan_sip.c:
<— Transmitting (NAT) to 216.115.69.144:5060 —>
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 216.115.69.144;branch=z9hG4bKf33.419f46c4090843a0c7ed973b5e6db5cb.0;received=216.115.69.144;rport=5060
Via: SIP/2.0/UDP 216.115.69.131;branch=z9hG4bKf33.a47369df893979bd23418fd2c651a491.0
Via: SIP/2.0/UDP 216.115.69.132;branch=z9hG4bKf33.c171fd5a1010d5f35ce97d967a887766.0
Via: SIP/2.0/UDP 4.55.17.35:5060;branch=z9hG4bK08B4aa91680ee9ea28a
Record-Route: sip:216.115.69.144;lr
Record-Route: sip:216.115.69.132;lr
From: sip:+12039796621@flowroute.com;tag=gK08
To: sip:+12036354616@flowroute.com
Call-ID: 1342726370_14996747@4.55.17.35
CSeq: 26854 INVITE
Server: FPBX-2.10.1(10.12.1)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: sip:12036354616@67.86.3.196:5060
Content-Length: 0

<------------>
[2013-04-08 18:53:03] VERBOSE[5228] chan_sip.c: Scheduling destruction of SIP dialog ‘1342726370_14996747@4.55.17.35’ in 32000 ms (Method: INVITE)
[2013-04-08 18:53:03] VERBOSE[5228] chan_sip.c:
<— Reliably Transmitting (NAT) to 216.115.69.144:5060 —>


SIP/2.0 603 Declined
****************************** note ******************************************************
Via: SIP/2.0/UDP 216.115.69.144;branch=z9hG4bKf33.419f46c4090843a0c7ed973b5e6db5cb.0;received=216.115.69.144;rport=5060
Via: SIP/2.0/UDP 216.115.69.131;branch=z9hG4bKf33.a47369df893979bd23418fd2c651a491.0
Via: SIP/2.0/UDP 216.115.69.132;branch=z9hG4bKf33.c171fd5a1010d5f35ce97d967a887766.0
Via: SIP/2.0/UDP 4.55.17.35:5060;branch=z9hG4bK08B4aa91680ee9ea28a
From: sip:+12039796621@flowroute.com;tag=gK081
To: sip:+12036354616@flowroute.com;tag=as062f2
Call-ID: 1342726370_14996747@4.55.17.35
CSeq: 26854 INVITE
Server: FPBX-2.10.1(10.12.1)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0

<------------>
[2013-04-08 18:53:03] VERBOSE[4430] chan_sip.c:
<— SIP read from UDP:216.115.69.144:5060 —>
ACK sip:12036354616@67.86.3.196:5060 SIP/2.0
Max-Forwards: 66
To: sip:+12036354616@flowroute.com;tag=as062f2bcd
From: sip:+12039796621@flowroute.com;tag=gK081
Via: SIP/2.0/UDP 216.115.69.144;branch=z9hG4bKf33.419f46c4090843a0c7ed973b5e6db5cb.0
Call-ID: 1342726370_14996747@4.55.17.35
CSeq: 26854 ACK
Content-Length: 0

<------------->
[2013-04-08 18:53:03] VERBOSE[4430] chan_sip.c: — (8 headers 0 lines) —
[2013-04-08 18:53:06] NOTICE[4430] chan_sip.c: Correct auth, but based on stale nonce received from ‘“Roger” sip:310@192.168.1.12:5060;tag=f98c2bf338’
[2013-04-08 18:53:14] NOTICE[4430] chan_sip.c: Correct auth, but based on stale nonce received from ‘“Bedroom” sip:315@192.168.1.12:5060;tag=2854c15b73’
[2013-04-08 18:53:15] NOTICE[4430] chan_sip.c: Correct auth, but based on stale nonce received from ‘“Bedroom” sip:315@192.168.1.12:5060;tag=18f939ec62’
[2013-04-08 18:53:21] VERBOSE[4430] chan_sip.c:
<— SIP read from UDP:216.115.69.144:5060 —>
OPTIONS sip:67.86.3.196:5060 SIP/2.0
Max-Forwards: 10
Record-Route: sip:216.115.69.144;lr
Via: SIP/2.0/UDP 216.115.69.144;branch=z9hG4bK26e6.433a3ed0dd64292904557a4c4316e945.0
Via: SIP/2.0/UDP 216.115.69.131:5060;branch=0
Route: sip:216.115.69.144;lr;received='sip:67.86.3.196:5060’
From: sip:ping@invalid;tag=06f30bd3
To: sip:67.86.3.196:5060
Call-ID: 704d6c77-f1802945-82db4d4@216.115.69.131
CSeq: 1 OPTIONS
Content-Length: 0

<------------->
[2013-04-08 18:53:21] VERBOSE[4430] chan_sip.c: — (11 headers 0 lines) —
[2013-04-08 18:53:21] VERBOSE[4430] chan_sip.c: Looking for s in from-sip-external (domain 67.86.3.196)
[2013-04-08 18:53:21] VERBOSE[4430] chan_sip.c:
<— Transmitting (NAT) to 216.115.69.144:5060 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 216.115.69.144;branch=z9hG4bK26e6.433a3ed0dd64292904557a4c4316e945.0;received=216.115.69.144;rport=5060
Via: SIP/2.0/UDP 216.115.69.131:5060;branch=0
Record-Route: sip:216.115.69.144;lr
From: sip:ping@invalid;tag=06f30bd3
To: sip:67.86.3.196:5060;tag=as52dc28a5
Call-ID: 704d6c77-f1802945-82db4d4@216.115.69.131
CSeq: 1 OPTIONS
Server: FPBX-2.10.1(10.12.1)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: sip:67.86.3.196:5060
Accept: application/sdp
Content-Length: 0

<------------>
[2013-04-08 18:53:23] NOTICE[5230] manager.c: Seems to have passed…
[2013-04-08 18:53:26] NOTICE[5232] manager.c: Seems to have passed…

The decision to send 603 has already been made before your trace starts, or you don’t have enough verbosity to show the dialplan operations…

603 will be used if no parameter is supplied to Hangup(), or if the parameter is not one for which there is a a known translation. In the latter case, there should be a debug level 1 message indicating the hangup cause that was passed to sip2cause.

Yes, but what will send a 404, that is the goal? I get great analyses of my problem but no solutions.

By the way, freePBX is executing: goto (app-blackhole,hangup,1)

I cannot find any documentation on app-blackhole. It may be that the actual hangup command is run in that app.

Solutions?

1, 2, or 3.

static const char *hangup_cause2sip(int cause) { switch (cause) { case AST_CAUSE_UNALLOCATED: /* 1 */ case AST_CAUSE_NO_ROUTE_DESTINATION: /* 3 IAX2: Can't find extension in context */ case AST_CAUSE_NO_ROUTE_TRANSIT_NET: /* 2 */ return "404 Not Found";

(However, 20 would be more semantically correct, although it generates a different 4xx code.)