Incoming call - AsteriskNow gives busy signal

Hi,

I have AsteriskNow Server and TalkSwitch IP PBX.
I created a SIP Trunk in AsteriskNow server with the following settings:

General Settings
Trunk name: 158
Outbound Caller ID: 158

Outgoing Settings
Trunk Name: T158
PEER Details:
host=90.0.0.110
username=158
secret=Removed
type=peer
nat=yes

Incoming Settings
USER Context: 158
USER Details:
context=from-talkswitch
type=user
secret=Removed

Registration
Register String:
158: Removed@90.0.0.110/158

I also enabled “Allow Anonymous Inbound SIP Calls” in the General Settings.

Where 90.0.0.110 is the IP of the TalkSwitch PBX.

The registration is successful, I can call from Asterisk to any extension in TalkSwitch also I can call PSTN and VIOP lines through TalkSwitch from Asterisk.

The problem, I cannot receive any calls into Asterisk through TalkSwitch, I always get busy signal.

Below is what I get in Asterisk log when calling from Analog phone connected to TalkSwitch into the SIP Trunk in Asterisk:
[Jan 22 10:28:20] VERBOSE[2732] netsock.c: == Using SIP RTP TOS bits 184
[Jan 22 10:28:20] VERBOSE[2732] netsock.c: == Using SIP RTP CoS mark 5

While below is what I get in Asterisk log when calling from IP phone connected to TalksSwitch into the SIP Trunk in Asterisk:
[Jan 22 19:37:48] VERBOSE[2725] netsock.c: == Using SIP RTP TOS bits 184
[Jan 22 19:37:48] VERBOSE[2725] netsock.c: == Using SIP RTP CoS mark 5
[Jan 22 19:37:48] WARNING[2725] chan_sip.c: username mismatch, have <158>, digest has <001A7E151>
[Jan 22 19:37:48] NOTICE[2725] chan_sip.c: Failed to authenticate device “My Office” sip:[email protected];tag=2632853575642027014

Any idea why I am getting the busy signal? And how to fix this problem?

can you check it enabling sip debug from the console with:

sip set debug on

It’s possible you’ll face with something like:

-- Executing [[email protected]:1] NoOp("SIP/192.168.1.100-00000003", "Received incoming SIP connection from unknown peer to 0123456789") in new stack
-- Executing [[email protected]:2] Set("SIP/192.168.1.100-00000003", "DID=0123456789") in new stack
-- Executing [[email protected]:3] Goto("SIP/192.168.1.100-00000003", "s,1") in new stack

it runs the [from-sip-external] (just an example… not had to be the same) and maybe it has a definitin of Congestion in the plan…

Finally, I got it working now.

What I did is just add “insecure=very” in the outgoing settings and make the incoming settings empty.

Now, outgoing calls and incoming calls are working fine.

Both systems Talkswitch and Asterisk look like one IP PBX box only.

Well, you are all over the place, insecure=very is not the correct format anymore (nor has been for 4 versions). The arguments are port and invite.

Insecure tells Asterisk to ignore authentication on inbound.

You don’t have a context.

You made need to set the fromuser or fromdomain variables.

See Asterisk sample sip.conf for an explanation of all the settings.

Hi, I found your post and I believe I set up everything correctly as follows:

Trunk Name: 199
Outbound CallerID: 199

Outgoing Settings:
Truck Name: T199
host=10.1.80.10
username=199
secret=199
type=peer
nat=yes
insecure=very

Incoming settings is blank.

Register is "199:[email protected]/199"

I have set up an extension on the Talkswitch to match as extension 199 with a user name of 199 and a password of 199 (I will increase the security once I get this to work).

The issue is that it won’t even register. I get a connection refused in the log files which would indicate either 1) my credentials are incorrect or there is an addressing or port issue. I believe it is not 2) because I have used an external SIP client with exactly the same settings and it works perfectly and registers. Therefore I believe it must be something in the way Asterisk is passing in the credentials.

Any help greatly appreciated!!

Thanks

Thanks for the feedback Scott. I was working off the original post from jalmod which said to use insecure=very to fix his incoming calls. I am new to Asterisk and just testing it out so this is my first try.

I will investigate your other suggestions. Obviously something has changed since when it worked for jalmod as they weren’t listed in his (presumably) working example.