Two roles that can share a server
A registrar accepts REGISTER requests and updates location bindings for an address of record. A proxy forwards SIP requests according to routing policy and can consult a location service to find contacts. One product can implement both roles, but they solve different problems. Successful registration means a binding was accepted. It does not establish a call, grant unrestricted outbound calling or prove that a later incoming request can reach the contact through NAT.
Multiple contacts and forking
An address of record can have multiple contact bindings when registrar policy permits it. A proxy may fork an incoming request to several destinations. This is why a claim that SIP inherently permits only one registered device is incorrect: a particular provider may impose that restriction, but it is not a universal SIP rule. For shared users, define which devices may register, how stale bindings expire and how simultaneous ringing should behave. Confirm that logout and credential rotation remove the access you intend to revoke.
Scaling the responsibility
When adding redundant servers, decide where registration state lives and how updates become available to the node routing a subsequent call. Sharing a DNS name alone does not share bindings. Likewise, a functioning registrar does not supply a media relay automatically. Draw registration writes, call-routing reads and media paths separately. Then test a registered endpoint after a node loss, after its network address changes and after a credential is revoked. If the design needs application-controlled calls, recording or media mixing, examine a B2BUA alongside the proxy rather than assuming location service provides PBX features.
Watch the explanation
Fred Posner explains how SIP routing, registration ownership and media services can be split across Kamailio, Asterisk and RTPengine. The discussion of backend probing and reconnect surges helps frame a larger deployment.
Read applicability and editorial notes →Watch this video here
AstriCon 2021 talk using Kamailio 5.5 examples. Treat it as an architecture lesson; our current written cluster uses 6.0 documentation. Review used the available transcript and primary references; audio and screen readability remain unverified.
The player loads only when you choose Watch here. Playback uses YouTube’s privacy-enhanced embed; YouTube processes playback data.
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.