Choose the registration owner
Kamailio's registrar module processes registration and uses location storage for bindings. A design can place registration at the edge, leave it with an application tier or use another supported arrangement. These choices change how subsequent requests find the endpoint and how failures are recovered. Do not let two systems independently assume they are the authoritative registrar without documenting how their state is related. A phone can show registered while a PBX cannot route an incoming call to its current contact.
One possible service architecture. Asterisk or FreeSWITCH supplies call applications; the proxy/registrar handles signaling policy. Media anchoring and state recovery must be designed explicitly.
Separate three policy decisions
Identify who authenticates the endpoint, who authorizes the destination and who selects the downstream application server. Authentication at an edge does not mean the application server should trust arbitrary caller-supplied headers or grant unrestricted outbound access. Preserve necessary dialog routing so in-dialog ACK, BYE and re-INVITE reach the correct state owner. If a media relay is used, define when it is allocated and how it is cleaned up on failed calls and cancellation races.
Test the lifecycle
Use a pilot endpoint to register, change network address, refresh, unregister and recover after a node restart. Then make a call through the PBX with hold, transfer and hangup. Inspect both the edge signaling and the PBX's independent legs. Record binding expiry, routing decisions and failover behavior. A shared database alone is not a complete high-availability design; transport connections, NAT reachability and live dialog state may require additional handling.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.