For the last few weeks I have been bashing away at trying to get an inbound SIP trunk to go somewhere sensible, rather than to ‘Number not in service’ message being played to a caller.
The problem is that the inbound SIP call is classified by Asterisk as an ‘Unknown Peer’ with an error message similar to: “Received incoming SIP connection from unknown peer to xxxxxxxxx”. This means that the call can’t be processed correctly. After processing the information from a selection of forums, I have come up with this solution.
This article describes the changes needed to allow incoming SIP calls to be processed correctly, like any other trunk. This article does not cover SIP extensions, only SIP trunks.
Important Security Notice: You can allow incoming SIP calls to function. This is achieved by setting ‘Allow anonymous inbound SIP calls’. However, this is a serious security risk. Use this feature to test the inbound SIP trunk calls, but you really need to correct this setting as quickly as possible. Have this setting enabled allows anyone who finds your IP address to make an inbound SIP connection. This at best will be really annoying, at worse with DISA could allow callers to establish free calls out of your system. You have been warned.
If inbound SIP calls work OK once you ‘Allow anonymous inbound SIP calls’, but once disabled again, you get ‘Service Unavailable’ type message, then you need to follow the details in the rest of this article.ion
Why does this happen? This is because the SIP trunk provider can not provide authentication details to you when the inbound SIP call arrives. Because there is no authentication, Asterisk will reject the request and effectively dumps the call. Once you add some verification information (namely an IP source), then Asterisk is able to validate the source of the call and can thus process it normally.
First, before you proceed any further, make sure you disable the ‘Allow anonymous inbound SIP calls’ in the General Settings area.
Under the definition of your SIP trunk, make sure you set the following settings under ‘Incoming Settings’:
USER Context:
Set this to the account name provided by your SIP trunk provider.
USER Details:
Ensure you have these additional settings:
type=friend
insecure=very
host=[IP|FQDN]
context=from-trunk
A quick explanation of these settings now follows:
The type=friend identifies this inbound trunk as friendly. The next setting of insecure=very sounds a nasty setting, however it advises Asterisk to check the host details. The host details are provided next, you need to supply the IP address or the FQDN (Fully Qualified Domain Name) of your SIP trunk provider. These are the details that will be validated before the call is accepted. The context=from-trunk is also required to identify the call route processing.
If this still fails, then also check your registration setting at the bottom of the SIP trunk definition.
This should be of the format:
account:password@my.sipprovider.com:port/sipextension
Where:
- account is your account name issued by you SIP trunk provider
- password is the password issued to you by your SIP trunk provider
- my.sipprovider.com is the IP address or FQDN of your SIP trunk provider
- port is the port number the SIP will come in, normally 5060
- sipextension is the SIP extension number assigned to your trunk. This maybe the same as account
Also don’t forget to check the Inbound Route uses the sipextension number or the internal routing may fail. Check the activity logs in the Asterisk console as the call comes in to see the DID number that will be used.
Related posts:
- HowTo: Securing Elastix This article covers the initial steps in securing the default...
- HowTo: Getting UK CLI working with DAHDI FXO UPDATED: This article details my findings on getting getting my...
- HowTo: Elastix DAHDI Trunk Routing with DID If you have multiple FXO (PSTN) lines into your PBX,...
- HowTo: Compress Elastix Logs Last Updated: 14 September 2009 One problem I noticed very...
- HowTo: Connecting a Grandstream to Elastix Last Updated: 03 October 2009 Originally Created: 03 October 2009...
I’ll second what Justin says about “context=from-trunk” in the Peer details, just allowed me to receive calls by adding this in! Thanks to both as this page has been really helpful too me!
Justin,
Glad to hear that you have had success. It is strange how you can bash away at something for ages and then come back to it ages later after seeing a fresh clue and it was the one point that helps resolve the problem.
Adam.
I’ve been fighting this issue for a long time. Your post spurred me to get to work on it once again. In the end, the one very specific change that got this working for me was adding “context=from-trunk” not in the USER Details, but in the PEER Details. I followed your instructions as well as those provided by my VoIP provider, and neither got it working. By adding the context to the USER section in addition to what your instructions advised, that finally got inbound calls working without allowing anonymous inbound SIP. Hope that helps in case anyone else finds themselves dealing with the same problem.