[PHREAKNET-64] 234 5700 unable to dial 980 5111
When dialling from Sean Reed 234 2700 to Paul Ash 980 5111 dial tone returned after dialling. This was apparent before the conversation this morning and is still apparent. I can still dial via the 234 1111 DISA to my node as demonstrated today. Sean says he will be at the switchboard later on today.
Comments
1/7/2026 1:13 PM — paulash134
As suggested by AI
1) I have ensured that the incoming 16555 traffic on the router is pointed towards the internal 192.168.1.176 IP of the Phreaknet server.
2) I have added the inbound external address of my router to the pjsip.conf
[transport-udp]
type = transport
protocol = udp
bind = 0.0.0.0:16555
tos = cs3
local_net = 192.168.1.0/24
external_media_address = 90.250.8.64
external_signaling_address = 90.250.8.64
3) I have amended the qualify_frequesncy = 20
lines-endpoint
type = endpoint
disallow = all
allow = ulaw
rtp_symmetric = yes
force_rport = yes
rewrite_contact = yes
direct_media = no
inband_progress = yes
tos_audio = ef
device_state_busy_at = 1
trust_id_outbound = no
trust_id_inbound = no
notify_early_inuse_ringing = yes
context = from-internal ; context in the dialplan in which this user originates a call
allow_subscribe = yes
subscribe_context = phreaknet-hints
call_group=10
pickup_group=10
lines-aor
type = aor
max_contacts = 3
qualify_frequency = 20
and for the operator extensions too
lines-operator-aor
type = aor
max_contacts = 3
qualify_frequency = 20
lines-auth
type = auth
lines-operator-trunk
type = endpoint
disallow = all
allow = ulaw
rtp_symmetric = yes
force_rport = yes
rewrite_contact = yes
direct_media = no
inband_progress = yes
tos_audio = ef
device_state_busy_at = 1
trust_id_outbound = no
trust_id_inbound = no
notify_early_inuse_ringing = yes
context = to-operator-trunk ;context in the dialplan in which this user originates a call
allow_subscribe = yes
subscribe_context = phreaknet-hints
dtmf_mode=inband
call_group=10
pickup_group=10
1/7/2026 5:07 PM — InterLinked
If a firewall issue, this is most likely related to IAX2 and not PJSIP in your case, since the PJSIP calls are within your network.
If you don't need public SIP registrations, you've actually just opened yourself up to attacks and not solved anything. I would undo what you did and ask questions on the mailing list before resorting to AI solutions that generally aren't correct.
1/8/2026 7:18 AM — paulash134
Thank you for the warning and the information, I have no idea if it is a firewall issue.
I am only using PJSIP and only have one other user out there who may try to register, but this has been unsuccessful so far.
Asking questions on the mailing list is a little daunting for me, I have found AI to be really helpful. I will try to ask the question on the mailing list but fear the responses.
You must be logged in to leave a comment.
1/4/2026 2:09 PM — InterLinked
It seems that things can get in a state where calls from 234 -> 980 don't go through (encounter IAX congestion) until a call is made from 980 -> 234. Then, it works both ways, for a while. Possibly some kind of network/firewall issue, or even IAX, but we'd need to confirm this and then maybe do some packet captures.