Linksys SPA3000: Context switches to public context when CID is turned on

Asterisk Asterisk SIP
1

My asterisk is on 192.168.7.2, and I have a SIPURA LinkSys SPA300 on the same LAN at 192.168.7.9.

asterisk configuration includes the following:

sip.conf:

[7000]
host=dynamic
secret=*****
context=from-ATA
type=friend

[SIPURA]
type=friend
port=5080
host=192.168.7.9

extensions.conf:

[from-ATA]
exten = 8888,1,Answer(1200)
exten = 8888,n,Verbose(3,Caller Id is [${CALLERID(all)}])
exten = 8888,n,Dial(SIP/8001&SIP/8002,20)
...

[SIPURA] is for my asterisk to register as the channel for outgoing PSTN calls.

The LinkSys ATA PSTN is registered using extension 7000:

2019-12-12%20Sipura%20Proxy

I forward incoming calls on the PSTN line to extension 8888 (Dial plan 8 contains <:8888>):

2019-12-12%20Sipura%20Forwarding

This has been doing fine for a few years. Recently I bought caller id service on the PSTN line. So I changed PSTN CID for VoIP CID to yes. That’s when I am seeing a weird phenomenon.

Whenever PSTN CID for VoIP CID is set to yes, the call to asterisk is in the public context :bangbang:

[Dec 12 10:17:53] NOTICE[522][C-0000009c]: chan_sip.c:26458 handle_request_invite: 
Call from 'SIPURA' (192.168.7.9:5080) to extension '8888' rejected 
because extension not found in context 'public'.

I took the risk and changed the context for dialplan 8888 to [public] momentarily just to test. The incoming call was handled correctly with this setting, and I could see the PSTN number in the CALLERID function.

When I set the PSTN CID for VoIP CID back to no, things work again (ie context is [from-ATA]), but of course without caller id information.

I am puzzled why this is happening. What have I done wrong?

2

The intended purpose of SIP registration is to tell the peer where to send incoming calls, so your reference to registering for outgoing calls leaves something out. Possibly the peer operates like type=peer, rather than type=user, and uses the IP address for authentication.

I suspect your primary problem is something to do with this distinction. Normally everything should be type=peer not type=friend, but it is looking as though the source address for incoming calls is not the same as the destination address for outgoing calls, so incoming calls are not being recognized in type=peer mode and, as the caller ID doesn’t match the peer name, they are falling back to allowguest=yes (something you should normally have set to no, as it has security implications).

I’d suggest changing allowguest to no, and making everything type=peer, then look closely at why the incoming calls are being rejected, and address that problem. Just setting allowguest to no may be enough to get log messages explaining how the peer appeared to be identifying itself.

3

Thank you! Your information did help to solve the problem, but only for a while.

By toggling between friend and peer, the incoming call will work correctly. But after some minutes or hours, the same Call from 'SIPURA' (192.168.7.9:5080) to extension '8888' rejected because extension not found in context 'public' would happen again.Then changing type for channel 7000 to the other value (ie to friend if it was currently peer, to peer if it was friend), would work again! But only for a while.

I read up the definitions of peer and friend, and actually think the proper type to use for channel 7000 should actually be user as it is to make calls only. But anyway, friend would be both user and peer, according to the definition.

https://www.voip-info.org/asterisk-sip-type says “if Asterisk can’t find a user that matches the incoming call, it will try to match the caller’s IP address with the IP addresses of known peers. If there’s no match at all, the call will be sent to the context defined in the [general] section of sip.conf.”

I suppose the use of the PSTN’s caller id by the Linksys ATA will make the caller no more user 7000. Shouldn’t then the IP always be used then?

I tried changing channel 7000’s context from from-ATA to SIPURA and also in extensions.conf the context for the dial plan for 8888 to SIPURA also, hoping that anything on 192.168.7.9 will now always be the SIPURA context. But the same problem (working only for a short while) exists.

I am puzzled by why it works only for a period after type is toggled. Any experience of this?

I suspect possibly the Linksys ATA is faulty and it’s IP address is wrong or missing.

4

Some ITSPs use multiple addresses to source calls.

5

But the NOTICE message says the call is coming from 192.168.7.9:5080. The IP address is correct. But I wonder why it says port 5080. 5080 is the port the on which the Linksys is listening (for dialing out PSTN calls).

Anyway, I found the pattern. My Linksys ATA PSTN Line registers with asterisk once every hour (3600s), see the first screenshot in my original question. Every time registration takes place, incoming PSTN calls to the ATA to asterisk will result in Call from 'SIPURA' (192.168.7.9:5080) to extension '8888' rejected because extension not found in context 'public'. If I then toggle the type value for channel 7000 and reload asterisk, incoming calls will work, until the ATA registers again! Is this clue helpful?

6

I’m confused. Assuming that 8888 doesn’t exist in public, that looks like the correct response to a call from 192.168.7.9:5080.

7

Extension 8888, ie the dialpan, is in context from-ATA, and channel 7000 has context from-ATA. The device (Linksys ATA) that registers as 7000 has IP 192.168.7.9. So when the device dials 8888, why is asterisk receiving it as public (or can’t find a matching context)?

Anyway, when it (ie receiving as public context) happens, all I need is toggle the value for type (peer/friend) for channel 7000 in sip.conf, reboot asterisk, and it will work, until the next time the LinkSys ATA re-registers.

8

According to your configuration, that address belongs to SIPURA, not 7000.

Also the failing call is identifying as user SIPURA, so both sides of the friend match will select the SIPURA peer.

If you actually know the address of the gateway, why are you configuring it to register; you should use a static address.

9

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.