Alternating type=peer/friend each time ATA re-registers

Asterisk Asterisk Support
1

I am starting a new question to follow up on this as there is some new information found.

I have the following on my LAN:

  • 192.168.7.2 asterisk v13
  • 192.168.7.9 Linksys SPA3000 - an ATA with FXO

I have a problem with receiving PSTN calls coming in from the Linksys ATA.

My sip.conf has:

[general]
allowguest=no
nat=comedia

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

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

The [SIPURA] channel was defined for asterisk to Dial outgoing PSTN calls through the Linksys ATA.

On the Linksys ATA, I register the PSTN Line to 192.168.7.2 using 7000 as User ID. When an incoming PSTN call is received on the Linksys, it is forwarded to VOIP extension 8888.

The Linksys is configured to use the PSTN’s caller ID, so in the FROM field on an INVITE it is no more 7000@192.168.7.2.

My extenstions.conf has:

[from-ATA]
exten = 8888,1,Answer(1200)
exten = 8888,n,Dial(SIP/8001&SIP/8002,10)
exten = 8888,n,Hangup

With the above as the start state, things work fine. Incoming PSTN calls are forwarded to 8888 complete with the PSTN caller ID and answered.

However, when the next time the Linksys registers (every 3600s), I will get:

NOTICE[522][C-0000011e]: 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’.

It stays that way for all incoming calls (even if the Linksys registers again), until I do the following as in the next paragraph.

By changing type to friend (from peer) in sip.conf for channel 7000, reloading asterisk, but changing nothing else, incoming calls will work again!

Then when the Linksys re-registers 3600s later, the same error will be there. And this time I have to change type back to peer for channel 7000, reload asterisk, and it will work again!

The problem and solution as I described is very consistent and entirely reproducible.

I tested out the above on a version 16 asterisk and the result is exactly the same.

I captured the SIP messages and the INVITE is exactly the same for for working and error situations up to a point. The working version is like:

<--- SIP read from UDP:192.168.7.9:5080 --->
INVITE sip:8888@192.168.7.2 SIP/2.0
Via: SIP/2.0/UDP 192.168.7.9:5080;branch=z9hG4bK-993f7bc0
From: Sipura <sip:2085132@192.168.7.2>;tag=ddd883f04f31dc40o1
To: <sip:8888@192.168.7.2>
Remote-Party-ID: Sipura <sip:2085132@192.168.7.2>;screen=yes;party=calling
Call-ID: 1f71a1b0-3555980@192.168.7.9
CSeq: 101 INVITE
Max-Forwards: 70
Contact: Sipura <sip:2085132@192.168.7.9:5080>
Expires: 240
User-Agent: Linksys/SPA3000-3.1.20(GW)
Content-Length: 440
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER
Supported: x-sipura, replaces
Content-Type: application/sdp

v=0
... rest of body deleted ...

<------------->
--- (15 headers 20 lines) ---
Sending to 192.168.7.9:5080 (no NAT)
Sending to 192.168.7.9:5080 (no NAT)
Using INVITE request as basis request - 1f71a1b0-3555980@192.168.7.9
Found peer '7000' for '2085132' from 192.168.7.9:5080

The not found in context 'public' situation produces the exact same (except those guid fields) exchange as the above but the last line is instead:

Found peer ‘SIPURA’ for ‘2085132’ from 192.168.7.9:5080

followed by some RTP and media lines and then:

Looking for 8888 in public (domain 192.168.7.2)

I am lost as to what I have done to result in the above.

Other than to duplicate the dial plan for 8888 in both from-ATA and public contexts, is there another solution?

2

As already said, if you know the IP address, don’t use host=dynamic and don’t ask the peer to register.

Also, don’t use different sip.conf entries for inbound and outbound calls via the same peer, or if you do, make sure that the outbound one has the same set up for incoming calls as the inbound one.

3

PS Don’t ask the same question in a different way on a new thread if you don’t like the first answer you got.

4

I registered it because the Linksys uses the option Make call without reg set to No to prevent anyone to dial out.

By set up, which parameters are you referring to?

5

context, codecs, variables being set, probably others.

If you are going to register, use the host=dynamic sip.conf entry for outgoing calls as well, however doing everything on static addresses is more correct and more secure.

6

This seems to solve the problem. I had thought that the in and out were two independent devices.

And it didn’t matter whether 7000 was a friend or peer. Both worked equally well.

Thanks for leading me to the solution.

7

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