“demo-bob” successfully registers on Asterisk and tries to dial outside:
[Sep 6 15:05:54] NOTICE[8906]: chan_sip.c:24933 handle_request_subscribe: Received SIP subscribe for peer without mailbox: demo-bob
== Using SIP RTP CoS mark 5
– Executing [99100@users:1] Dial(“SIP/demo-bob-00000000”, “SIP/100@isp”) in new stack
== Using SIP RTP CoS mark 5
– Called SIP/100@isp
[Sep 6 15:05:56] NOTICE[8906]: chan_sip.c:20425 handle_response_invite: Failed to authenticate on INVITE to ‘“demo-bob” sip:demo-bob@10.10.10.100;tag=as38288baa’
– SIP/isp-00000001 is circuit-busy
== Everyone is busy/congested at this time (1:0/1/0)
– Auto fallthrough, channel ‘SIP/demo-bob-00000000’ status is ‘CONGESTION’
insecure=very has been replaced by a comma separated list of its component parts. It is an unusual system that actually needed very, rather than invite.
ISP is my own SIP trunk on another softswitch, it does NOT require any kind of authentication. And now I don’t see any packet from this Asterisk
I know about security flaws, it is firewalled test machine. I just want to make this configuration work as I expect. Now it even don’t tries to dial to “isp”, and i can’t figure out why.
Looking more carefully, it is demo-bob that is complaining about the invalid authentication. As it handle_[color=#FF0000]response[/color]_invite, it is defnitely the remote system that is rejecting the password, not Asterisk.
If you are using a supported version of asterisk, you still need to fix insecure, if it is actually needed, as insecure=very will be ignored and result in the default bahaviour.
Removing insecure does nothing. It was already being ignored as invalid.
Looking more closely, it is sending to 10.10.10.100, and that is requiring a password. I don’t know why it is sending to user demo-bob (I misread that as the device name), there, rather than 100. You have no password specified for isp.
HOWEVER, you should only send without password if the destination doesn’t require one. The call is failing because the destination does require one.
From other threads, it does look like some old versions of Asterisk treat SIP/xxx@yyy as equivalent to Local/xxx@yyy, at least if yyy is a valid context, so you might be safer using the SIP/yyy/xxx format.
(The insecure is not needed if there is no password. insecure=invite is needed if you need a password for outgoing calls, but the remote side isn’t prepared to send the same one for incoming ones.)