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  host=dynamic secret=*** context=from-ATA type=peer [SIPURA] type=peer port=5080 host=192.168.7.9
[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 email@example.com.
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[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:firstname.lastname@example.org SIP/2.0 Via: SIP/2.0/UDP 192.168.7.9:5080;branch=z9hG4bK-993f7bc0 From: Sipura <sip:email@example.com>;tag=ddd883f04f31dc40o1 To: <sip:firstname.lastname@example.org> Remote-Party-ID: Sipura <sip:email@example.com>;screen=yes;party=calling Call-ID: firstname.lastname@example.org CSeq: 101 INVITE Max-Forwards: 70 Contact: Sipura <sip:email@example.com: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 - firstname.lastname@example.org Found peer '7000' for '2085132' from 192.168.7.9:5080
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
public contexts, is there another solution?