I am using Asterisk certified/13.1-cert7 In the systems I maintain. There are two general structures in these systems and I’m experiencing the issue on both types of system:
Endpoint <-SIP-> Asterisk <-IAX2-> Asterisk <-SIP-> SBC (Trunk)
Endpoint <-SIP-> Asterisk <-SIP-> SBC (Trunk)
The issue is that on inbound calls (from the trunk to the endpoint), the endpoint is sending a SIP 404 unavailable to Asterisk but the code being sent to the trunk is 503. This is causing the trunk to repeatedly issue another SIP INVITE. Since we monitor traffic on these systems we are getting spammed with tons of call attempt notifications when this scenario exists.
I found several closed issues that sound related to this same type of issue in JIRA, they are all for previous versions. I captured several files of console output but I didn’t want to post a word wall unless I know that it will be useful, and I am not very well versed in debugging Asterisk. Prior to recently my scope was only working in the dialplan, so forgive inexperience. I’m relying on the community to school me in collecting effective Asterisk debug artifacts.
Thanks in advance for help on this issue.
The peer is broken. 4xx errors allow retries. 5xx errors are permanent and shouldn’t result in a retry. It looks like the peer has it the wrong way round.
Asterisk is basically an ISDN PABX, so it translates SIP statuses into ISDN cause codes and back again. I believe there is a standard for how that should be done, and it probably does result in 404 becoming 503.
Thanks for your reply @david551, I’ll look for such a standard (my quick search turned up RFC 3398) to help me understand how the translation works.
For clarification, when you say that the peer is broken… by peer do you mean what I’m calling my endpoint or my SIP trunk?
Whatever is retrying on a 5xx response.
These errors occurs when there are no IP or Host or peer with the specified SIP address.
Make sure the proper IP, codec, DTMF and authentication configured between asterisk and SBC / peer.
It is a cause code for SIP device.
404 is coming from the remote system and I think the OP understands why. It could well be that what is missing on that system is the equivalent of an Asterisk extension, not an Asterisk device, but, in any case the issue here isn’t why there is 404, but how Asterisk transforms it.
Translating SIP responses is an interesting thing - because sometimes it can depend on how you look at it. In this case a 404 may be appropriate on one side, because the extension wasn’t found. From Asterisk to the caller though the extension was found but Asterisk failed to handle the call. It all… depends… which complicates things. You may be able to use the cause code functionality to Hangup() to explicitly set a cause code that maps to 404 if the outgoing side is 404. I believe the wiki has mappings and information but it’s certainly something that has to be experimented with.