[FreePBX issue during call platform migration] all circuits busy

[mkaye]

started today - maybe last week on sone numbers - all numbers now
tried voip2
switched to backup freepbx - same
have other trunk with voip.ms, working fine
fairly sure this is a freephoneline issue

[Liptonbrisk]

I’m leaning towards the call platform migration having changed something on Freephoneline’s side, possibly in a way that now interacts badly with your FreePBX trunk.

Incoming and outgoing calls work on 4 different FPL accounts I tested using voip2.freephoneline.ca:5060 just now, registered in different provinces.
I tested calling to Telus and Bell carrier numbers. Telus to FPL and FPL to FPL worked as well. I used MicroSIP app (which is free to use and test with) and Obihai devices. It seems to me that you should be using MicroSIP or another app to confirm your findings.

The problem could be specific to an area code with a specific carrier (or isolated to a specific carrier). I would probably need some examples of business phone numbers I could call to test, since I numbers I am calling work fine. Call/SIP logs may be useful. I doubt this is the problem though. I think it's a result of the call platform migration and your FreePBX config.

Visit viewtopic.php?t=21062. I don't know if troubleshooting is worthwhile during the call platform migration period. If the SIP error code is 503, that may indicate a trunk-capacity or interconnect issue on Freephoneline's platform-migration side. More importantly, I see that you had the same issue back in 2024 with pjsip: viewtopic.php?p=81393#p81393. Having hit a similar "all circuits busy" problem with FreePBX/PJSIP before suggests this could be a recurring pattern with a PBX-side configuration interacting poorly with certain trunk conditions. That is, the new failure could reflect either a Freephoneline platform change or a pre-existing FreePBX quirk that the migration exposed.

If the real SIP code is 403 rather than 503, then Freephoneline is rejecting the call. In that case, I’d suspect PortaSIP/FPL doesn’t like the source IP, NAT presentation, or some other trunk identity detail, rather than a simple busy-trunk condition. This Fongo admin information is relevant because it shows Freephoneline has rejected SIP traffic for malformed packets and header issues before: viewtopic.php?p=82971#p82971.

"Hi,

In the last 24 hours there have been a few issues with Freephoneline's sip proxies due to invalid sip packets overloading the parser and causing a crash and restart.

Due to this we have enabled the sanity check module on them which prevalidates the sip headers before processing and will drop the connection of they do not pass.


The main ones we are seeing rejections for currently right now are

1. Body length not matching content length

2. Invalid proxy require header being sent."

-- Fongo admin

Since you’re using FreePBX/PJSIP, that doesn’t map to ATA settings, such as Proxy-Require, but it does support the idea that Freephoneline may be sensitive to SIP presentation details, especially NAT/Via/Contact headers and source IP, and could be returning 403 for that reason. Also, viewtopic.php?t=20896 shows Freephoneline is enforcing host-name verification/server identity checks. If your FreePBX trunk is using anything nonstandard, such as direct IP, mismatched domain, or server-name settings that don’t match Freephoneline's, that could result in a 403 rejection or other call failure.

[mkaye]

[2026-07-25 13:23:43] WARNING[1800][C-00000326] chan_sip.c: Received response: "Forbidden" from '"M&D Kaye" <sip:[email protected]>;tag=as276ab439'

this is the only msg in the log when i attempt to call out

not using pjsip, just sip

[Liptonbrisk]

[2026-07-25 13:23:43] WARNING[1800][C-00000326] chan_sip.c: Received response: "Forbidden" from '"M&D Kaye" <sip:[email protected]>;tag=as276ab439'

That's 403 Forbidden. So, it's not just a generic busy-trunk symptom. This seems to me that the call platform migration changed something on Freephoneline’s/PortaSIP's side that is now rejecting how your FreePBX trunk is presenting itself. The fact that the log shows Forbidden means Freephoneline is refusing the SIP request at the provider layer. Typical 403 causes include source IP mismatch, incorrect NAT/Via presentation, caller ID not approved, invalid number format, or the provider not liking the Contact header. So my theory is that the migration exposed something in your FreePBX SIP presentation that Freephoneline now rejects.

If you provision the same FPL credentials on MicroSIP and it works, then the issue is in the FreePBX config rather than the FPL account: viewtopic.php?t=20772.

[mkaye]

this what i have used for years, except voip, not voip2 - is something missing or wrong?

username=1613xxxxxxx
type=peer
timers=no
session-timers=refuse
secret=xxxxxxxx
qualify=yes
nat=yes
keepalive=20
insecure=invite
host=voip2.freephoneline.ca
fromdomain=voip2.freephoneline.ca
dtmfmode=rfc2833
disallow=all
context=from-trunk
allow=ulaw

[Liptonbrisk]

The problem is that I don't have FreePBX set to up to test if anything changed after call migration (also, it's ongoing, so I don't know what else might change, which is why I think troubleshooting might be pointless).

The trunk definition looks reasonable for chan_sip, but it doesn’t prove the SIP presentation is what Freephoneline now expects. The log you posted is the key point: chan_sip is receiving a SIP rejection from Freephoneline, so this is not just some generic “busy trunk” symptom. Something about your FreePBX config is no longer being accepted. I'd try to verify that the trunk is registering cleanly. After that, I’d compare the FreePBX SIP presentation against a working softphone, such as MicroSIP, because if MicroSIP works with the same account, the problem is in your FreePBX/chan_sip setup rather than the account itself. If your FPL account is blocked, troubleshooting is also pointless. I doubt your account is blocked, but it may be worth checking.

I’d suspect source IP, NAT/Via, caller ID, or some other trunk identity mismatch. You'll probably need someone with a working FreePBX config with FPL to assist, and you might want to try asking here: https://community.freepbx.org/.

For logs, I think this was the process for collection:

1. SSH into the FreePBX server. If you don't have server access (only WebGUI), I guess it's game over.

2. Run asterisk -rvvv.

3. Leave that terminal open while you test the outbound call.

4. Enable SIP debugging

5. At the Asterisk prompt, run sip set debug on.

You can target the provider IP only, I think: sip set debug 162.213.111.22
If you want to disable it later, run sip set debug off.

6. Reproduce the problem

Place the outbound call that is failing.

Watch the CLI output for the INVITE and FPL’s response.

Look specifically for the Forbidden response and any headers around it, such as Via, Contact, From, User-Agent, and Content-Length.

7. Check the full log

In another SSH session, run tail -f /var/log/asterisk/full.

Repeat the call again if needed.

Save the relevant section of the log that includes the outbound attempt and the returned SIP response.

8. This is optional: capture security events

Check /var/log/asterisk/security for any blocked registrations or suspicious SIP events.

This is useful if the provider or firewall is reacting to repeated attempt (I doubt it).

9. Optional: run sngrep on the box to view the SIP dialog.



10. What to save for troubleshooting

- the exact CLI lines around the failed call

- the Forbidden response and the headers immediately above it

- The relevant /var/log/asterisk/full excerpt.

If possible, collect the SIP INVITE and response from sngrep

11. What might help

-- whether you see the trunk registering successfully

-- the exact Forbidden lines and several lines before and after them.

-- Any User-Agent, From, Contact, or Via headers that look unusual


But I'm pretty limited in that I'm not using FreePBX and can't check to see what works. You'll likely need help from someone else.

[ilneofita]

I add the problem in my asterisk using pjsip
I solved adding in my _endpoint to force the authentication
outbound_auth=montreal_auth

Try to add in sip.conf
fromuser=1613xxxxxxx
defaultuser=1613xxxxxxx

[mkaye]

*deleted by LiptonBrisk for privacy*

[ilneofita]

Try to add authuser and in the log remove the number

[mkaye]

sorry, not sure how at add authuser - i just know enough to be dangerous...

[ilneofita]

in your conf try to add
authuser=1613xxxxxxx

and if you didn't add these already, try too
fromuser=1613xxxxxxx
defaultuser=1613xxxxxxx

Sorry I don't use freepbx

Edit: you previous post too mask the number

[Liptonbrisk]

Okay, the call is being sent via the old chan_sip trunk, despite the internal extension being PJSIP. The call starts on a PJSIP endpoint, then FreePBX hands it off to the chan_sip trunk, and the failure is happening at the trunk/provider layer.

Anyway, the failing leg is still SIP/freephoneline, and Asterisk gets Forbidden from Freephoneline on that trunk leg.

This is not a raw SIP packet trace, but it does show the dialplan and the final Forbidden result.

The full outbound INVITE or the inbound 403 headers are not included. So I can't prove if the problem is due to From/caller-ID identity, Contact or Via containing the wrong private/public address, source IP allowlisting or NAT, User-Agent or another SIP header, account-side restriction, a new FPL/PortaSIP validation rule. It's possible I may not be able to tell, regardless.

FPL/PortaSIP is probably rejecting an outbound identity/presentation detail. I don't think that type=peer, qualify=yes, session timers, codec selection, or 3600-second registration expiry suddenly broke today.

Try this:

asterisk -rvvv
sip set debug peer freephoneline

Then place one failed outbound call, and copy the entire INVITE plus the SIP/2.0 403 Forbidden response, with credentials, public IP addresses, Call-ID, tags, and nonces redacted (edited to something private).

The key headers to retain are From, To, Via, Contact, User-Agent, Proxy-Require (if present), Supported, Allow, CSeq, and Content-Length.

Afterwards, enter

sip set debug off

The full Asterisk log is typically at /var/log/asterisk/full, but the debug capture is what should show the exact request FPL is refusing.

[Liptonbrisk]

in your conf try to add
authuser=1613xxxxxxx

and if you didn't add these already, try too
fromuser=1613xxxxxxx
defaultuser=1613xxxxxxx

Sorry I don't use freepbx

Edit: you previous post too mask the number

Okay, @mkaye, maybe you can try this to see if it helps:

1) In the FreePBX GUI go to Connectivity --> Trunks --> select the chan_sip trunk for Freephoneline.

2. Under SIP Settings --> Outgoing (Peer Details), add these lines (replace with your real digits):

a) authuser=1613xxxxxxx

b) fromuser=1613xxxxxxx

c) defaultuser=1613xxxxxxx


authuser=1613xxxxxxx -- This is the username sent for authentication challenges (same as authuser in many ATA/peer examples).

fromuser=1613xxxxxxx -- This forces the SIP From: username (the identity FPL sees as the caller).

defaultuser=1613xxxxxxx -- This is used when host is not dynamic. It's often equivalent to the login name Asterisk uses when registering/outbound. Baiscally, it's the main user identity Asterisk assumes for that trunk when no specific value is being used.



2. In Registration Settings, add the register string if required:

1613xxxxxxx:[email protected]/1613xxxxxxx (only if your trunk uses registration; I think Freephoneline requires registration for outbound calls to work past 15 minutes)

3. Submit, and Apply Config.


4. Then either reload Asterisk or at the Asterisk CLI run this: sip reload


I'm guessing a bit.


Test an outbound call.

[Liptonbrisk]

Edit: you previous post too mask the number

Yes, I deleted the log. Thank you.

[mkaye]

INVITE sip:[REDACTED]@voip.freephoneline.ca SIP/2.0
Via: SIP/2.0/UDP 192.168.100.139:5060;branch=z9hG4bK50066b2c;rport
Max-Forwards: 70
From: "M&D Kaye" <sip:[REDACTED]@voip2.freephoneline.ca>;tag=as5b7fd5d8
To: <sip:[REDACTED]@voip.freephoneline.ca>
Contact: <sip:[REDACTED]@192.168.100.139:5060>
Call-ID: [email protected]
CSeq: 102 INVITE
User-Agent: FPBX-17.0.30(20.15.2)
Date: Sat, 25 Jul 2026 19:30:22 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces
Content-Type: application/sdp
Content-Length: 254
v=0
o=root 33018189 33018189 IN IP4 192.168.100.139
s=Asterisk PBX 20.15.2
c=IN IP4 192.168.100.139
t=0 0
m=audio 16584 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:140
a=sendrecv
---
-- Called SIP/freephoneline/[REDACTED]
<--- SIP read from UDP:162.213.111.25:5060 --->
SIP/2.0 403 You must be registered to make a call
Via: SIP/2.0/UDP 192.168.100.139:5060;branch=z9hG4bK50066b2c;rport=5060;received=142.189.179.241
From: "M&D Kaye" <sip:[REDACTED]@voip2.freephoneline.ca>;tag=as5b7fd5d8
To: <sip:[REDACTED]@voip.freephoneline.ca>;tag=b27e1a1d33761e85846fc98f5f3a7e58.0efd
Call-ID: [email protected]
CSeq: 102 INVITE
Server: Freephoneline Proxy
Content-Length: 0
<------------->
--- (8 headers 0 lines) ---
Transmitting (NAT) to 162.213.111.25:5060:
ACK sip:[REDACTED]@voip.freephoneline.ca SIP/2.0
Via: SIP/2.0/UDP 192.168.100.139:5060;branch=z9hG4bK50066b2c;rport
Max-Forwards: 70
From: "M&D Kaye" <sip:[REDACTED]@voip2.freephoneline.ca>;tag=as5b7fd5d8
To: <sip:[REDACTED]@voip.freephoneline.ca>;tag=b27e1a1d33761e85846fc98f5f3a7e58.0efd
Contact: <sip:[REDACTED]@192.168.100.139:5060>
Call-ID: [email protected]
CSeq: 102 ACK
User-Agent: FPBX-17.0.30(20.15.2)
Content-Length: 0
---
[2026-07-25 15:30:22] WARNING[1800][C-00000328]: chan_sip.c:24444 handle_response_invite: Received response: "Forbidden" from '"M&D Kaye" <sip:[REDACTED]@voip2.freephoneline.ca>;tag=as5b7fd5d8'

== Spawn extension (from-trunk, [REDACTED], 1) exited non-zero on 'SIP/freephoneline-000002ea'

[mkaye]

added these - still fails

2. Under SIP Settings --> Outgoing (Peer Details), add these lines (replace with your real digits):

a) authuser=1613xxxxxxx

b) fromuser=1613xxxxxxx

c) defaultuser=1613xxxxxxx

[Liptonbrisk]

SIP/2.0 403 You must be registered to make a call

Let's focus on this while I type up a response.

Mkaye’s trunk is probably not being accepted as registered by Freephoneline, and the SIP exchange shows a server/identity mismatch: the outbound INVITE goes to voip.freephoneline.ca, while the trunk identity still references voip2.freephoneline.ca.

[Liptonbrisk]

Freephoneline is refusing this outbound INVITE because it does not accept the account as registered for the request. The log also shows that the call originated over a chan_sip trunk (SIP/freephoneline-. . . and chan_sip.c), even though the internal extension is PJSIP, but I'm not sure that's important.

Let's make the trunk use voip2.freephoneline.ca consistently for both registration and outbound settings, and ensure the registration interval/expiry is set to 3600. In practice that means setting host and fromdomain to voip2.freephoneline.ca, using the correct SIP username/password, and confirming the trunk shows registered before placing a call.


I'll be editing this post, while I look up settings.

[mkaye]

i have voip2 for host & fromname
if i log into fpl, it shows connected

[Liptonbrisk]

Back up the existing trunk configuration

1. In FreePBX, go to Connectivity --> Trunks --> freephoneline. Copy the existing settings somewhere safe before changing anything:

Outgoing PEER Details

Incoming USER Details, if present

Registration string / Register String

Any custom SIP settings

2. Check whether Asterisk is registered

a) At the Asterisk CLI, run this:

Code: Select all

sip show registry

b) Find the Freephoneline entry. The important result is

Code: Select all

Registered

If it says Request Sent, Rejected, No Authentication, Timeout, or there is no Freephoneline entry at all, stop: the issue is registration and not outbound caller ID.

3. Check the configured trunk peer. At the Asterisk CLI, run this:

Code: Select all

sip show peer freephoneline

a) Confirm that the peer's configured host is the server you intend to use:

Code: Select all

voip2.freephoneline.ca

b) Also check the peer’s status and whether Asterisk has resolved the host successfully. Do not rely only on FreePBX's dashboard “online” indication.

[mkaye]

Host dnsmgr Username Refresh State Reg.Time
voip2.freephoneline.ca:5060 Y xxxxxxxxxx 3585 Registered Sat, 25 Jul 2026 15:55:58
1 SIP registrations.
NUC1*CLI> sip show peer freephoneline


* Name : freephoneline
Description :
Secret : <Set>
MD5Secret : <Not set>
Remote Secret: <Not set>
Context : from-trunk
Record On feature : automon
Record Off feature : automon
Subscr.Cont. : <Not set>
Language : en
Tonezone : <Not set>
AMA flags : Unknown
Transfer mode: open
CallingPres : Presentation Allowed, Not Screened
FromUser : xxxxxxxxxxx
FromDomain : voip2.freephoneline.ca Port 5060
Callgroup :
Pickupgroup :
Named Callgr :
Nam. Pickupgr:
MOH Suggest :
Mailbox :
VM Extension : *97
LastMsgsSent : 0/0
Call limit : 0
Max forwards : 0
Dynamic : No
Callerid : "" <>
MaxCallBR : 384 kbps
Expire : -1
Insecure : invite
Force rport : Yes
Symmetric RTP: Yes
ACL : No
ContactACL : No
DirectMedACL : No
T.38 support : Yes
T.38 EC mode : Redundancy
T.38 MaxDtgrm: 400
DirectMedia : No
PromiscRedir : No
User=Phone : No
Video Support: No
Text Support : No
Ign SDP ver : No
Trust RPID : No
Send RPID : No
Path support : No
Path : N/A
TrustIDOutbnd: Legacy
Subscriptions: Yes
Overlap dial : Yes
DTMFmode : rfc2833
Timer T1 : 500
Timer B : 32000
ToHost : voip.freephoneline.ca
Addr->IP : 162.213.111.25:5060
Defaddr->IP : (null)
Prim.Transp. : UDP
Allowed.Trsp : UDP
Def. Username: xxxxxxxxxxx
SIP Options : (none)
Codecs : (ulaw)
Auto-Framing : No
Status : OK (24 ms)
Useragent :
Reg. Contact :
Qualify Freq : 60000 ms
Keepalive : 20000 ms
Sess-Timers : Refuse
Sess-Refresh : uas
Sess-Expires : 1800 secs
Min-Sess : 90 secs
RTP Engine : asterisk
Parkinglot :
Use Reason : No
Encryption : No
RTCP Mux : No

Reliably Transmitting (NAT) to 162.213.111.25:5060:
OPTIONS sip:voip.freephoneline.ca SIP/2.0
Via: SIP/2.0/UDP 192.168.100.139:5060;branch=z9hG4bK3f5f1c15;rport
Max-Forwards: 70
From: "Unknown" <sip:[email protected]>;tag=as211b419d
To: <sip:voip.freephoneline.ca>
Contact: <sip:[email protected]:5060>
Call-ID: [email protected]:5060
CSeq: 102 OPTIONS
User-Agent: FPBX-17.0.30(20.15.2)
Date: Sat, 25 Jul 2026 20:09:58 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces
Content-Length: 0

---

i see voip & voip2 - not sure why??
i tried changing back to voip so everything would match - still failed

[Liptonbrisk]

4. Check the actual REGISTER exchange. Enable SIP logging:

a)

Code: Select all

sip set debug on

Then force a SIP reload:

b)

Code: Select all

sip reload

Watch for the REGISTER request to

Code: Select all

voip2.freephoneline.ca

and its final response. A normal digest-auth sequence may show a challenge first, but it must finish with

Code: Select all

SIP/2.0 200 OK

c) Then turn debug back off:

Code: Select all

sip set debug off

5. Correct the registration string only if it is absent or points elsewhere

If the registration string is missing, is malformed, or targets a server other than

Code: Select all

voip2.freephoneline.ca

, then edit it in the trunk’s Registration / Register String field.

a) Use this format:

Code: Select all

SIP_USERNAME:[email protected]/SIP_USERNAME

Replace both instances of

Code: Select all

SIP_USERNAME

with the Freephoneline SIP username, and

Code: Select all

SIP_PASSWORD

with the VoIP/SIP password—not necessarily the account-portal password.

Example format only:

Code: Select all

1613xxxxxxx:[email protected]/1613xxxxxxx

b) Save the trunk, and click Apply Config. Then rerun:

Code: Select all

sip show registry

Do not place a test call until it reports

Code: Select all

Registered

6. Keep the outbound peer on voip2

In the trunk’s PEER Details, ensure the outbound target is

Code: Select all

host=voip2.freephoneline.ca

7. Test once, with a targeted SIP trace[/b]

After

Code: Select all

sip show registry

says

Code: Select all

Registered

:

a) Run

Code: Select all

sip set debug on

b) Place one outbound call.

c) Confirm the REGISTER target and INVITE destination are both voip2.freephoneline.ca.

d) If the INVITE still receives the same 403, save the REGISTER sequence and INVITE/403 sequence for comparison.

e) Run

Code: Select all

sip set debug off

.



If it is already Registered

If

Code: Select all

sip show registry

already says

Code: Select all

Registered

against voip2.freephoneline.ca, then the likely problem is not that “the trunk failed to register.” The next evidence needed is the actual REGISTER exchange and the complete configured PEER Details, with usernames/passwords redacted. At that point, check if the account is blocked (MicroSIP). Try logging in at https://www.freephoneline.ca/accountInfo.

[Liptonbrisk]

I've got someone coming over to install a new AC unit. So, if it doesn't bother you I'm just going to run this problem through A.I. At worst, it's completely wrong. At best, it's going to save me from having to look up setting locations constantly (because I'm not using FreePBX currently). Hold on . . .

[Liptonbrisk]

i see voip & voip2 - not sure why??
i tried changing back to voip so everything would match - still failed

A.I. Response:

If you changed back to `voip` “so everything would match,” that would **not** necessarily fix anything. The important part is not that every string says the same hostname; it’s that the **registered server and the actual provider state are valid**.

## What the log now tells us

- `sip show registry` says the trunk is **Registered** to `voip2.freephoneline.ca:5060`.
- `sip show peer freephoneline` shows `FromDomain : voip2.freephoneline.ca`, `ToHost : voip.freephoneline.ca`, and `Addr->IP : 162.213.111.25:5060`.

- The actual call is then rejected with `403 You must be registered to make a call`.

That means the trunk is not just “offline.” It is registered, but the outbound call is still being refused. So the next problem is likely **not basic registration**, but a mismatch between the registered identity and the outbound request that Freephoneline is evaluating.

## Why you see both voip and voip2

The `sip show peer` output contains both because Asterisk stores different roles separately:

- `FromDomain` is the domain used in SIP identity headers.
- `ToHost` is the destination host Asterisk is actually sending to.
- `Addr->IP` is the resolved IP address for the host.

So seeing both `voip2` and `voip` in the same peer dump does **not** automatically mean the trunk is wrong. It means Asterisk is using one value for identity-related fields and another for the network destination.

## What to do next

1. Keep the server registered to `voip2.freephoneline.ca` since registration is already working.

2. Do **not** switch to `voip.freephoneline.ca` just to make the names match; that is not what the data supports.

3. Check the trunk’s outbound PEER Details for the exact values of `username`, `fromuser`, `defaultuser`, and any custom SIP headers.

4. Capture one full outbound INVITE with SIP debug enabled and compare the `From`, `To`, `Request-URI`, and auth headers to the registered account.

5. If needed, test whether removing custom outbound CID manipulation changes the response, because the log shows the trunk is also applying a specific trunk caller ID.

[Liptonbrisk]

I've got someone coming over to install a new AC unit. So, if it doesn't bother you I'm just going to run this problem through A.I. At worst, it's completely wrong. At best, it's going to save me from having to look up setting locations constantly (because I'm not using FreePBX currently). Hold on . . .

A.I. response is as follows:

## Full FreePBX steps

### 1) Keep the trunk on voip2
Since registration is already working, leave the trunk registering to `voip2.freephoneline.ca`. Do **not** switch back to `voip.freephoneline.ca` just to make the labels match, because Freephoneline has used multiple SIP hosts and the important part is that the account registers successfully.

**Liptonbrisk says, "Unh, host name matters. Porta [the switch/server vendor] recommended to Fibernetics [CLEC/network used by Fongo/Freephoneline] to enable Host Name Verification on Sip Registrations. This was enabled." The trunk must present the same host name the provider expects in the SIP registration and related identity fields. That makes the voip vs voip2 distinction potentially important, because a host-name mismatch can break call acceptance even when the account page shows connected.

### 2) Set the trunk to `type=peer`
For the Freephoneline SIP trunk, use `type=peer` rather than `friend`. `peer` is the standard trunk model in Asterisk, and `friend` is not needed here.

**Liptonbrisk says, "Uhhh, it already is set to peer, but whatever."**


### 3) Verify the trunk basics
In **Connectivity > Trunks > freephoneline**, check the Outgoing PEER Details for:

- `host=voip2.freephoneline.ca`
- `username=your SIP username`
- `secret=your SIP password`
- `fromdomain=voip2.freephoneline.ca`
- `disallow=all`
- `allow=ulaw`


### 4) Set the register string
Use the standard register string format:

```text
SIPusername:[email protected]/SIPusername
```

This is the same basic Freephoneline format used in the community guide, with the host pointed at `voip2`.

### 5) Set registration timers to 3600
In **Settings > Asterisk SIP Settings** or the SIP timer fields for the trunk, set:


Default Expiry / defaultexpiry: 3600 for Freephoneline.

For the trunk itself

If the trunk has a per-trunk registration string or per-trunk expiry value, use:

Registration Expiry: 3600




### 6) Apply config and confirm registration
Click **Submit**, then **Apply Config**, and reload SIP. Then run:

```bash
sip show registry
sip show peer freephoneline
```

You want to see `Registered` and `Status: OK`.

### 7) Temporarily remove outbound caller-ID customization

Your log shows FreePBX is applying a trunk caller ID (`TRUNKOUTCIDMD Kaye 613xxxx` and `CALLERIDall...`) before the call is sent. Temporarily clear or disable custom outbound caller ID on the trunk and test again, because the trunk is already registered and the remaining failure is now more likely about the outbound INVITE identity than the registration itself.

### 8) Place one test call with SIP debug on
Turn on SIP debug, place one call, and inspect the INVITE. You are looking for whether the call is being sent with the username, domain, and caller ID you expect. If it still comes back `403 You must be registered to make a call`, the next likely culprit is the outbound identity fields, not the expiry value. [community.asterisk](https://community.asterisk.org/t/cannot ... ider/30556)



## Most likely remaining issue

At this point, the most likely remaining cause is **outbound caller-ID or SIP identity handling**, especially because the trunk is registered successfully and the log shows FreePBX actively rewriting outbound caller ID before the call leaves the box. The actual fix is likely to be in the outbound trunk identity/caller-ID settings rather than the timer itself.