FreeSWITCH SIP Profiles vs Asterisk PJSIP Endpoints

FreeSWITCH SIP profiles and Asterisk PJSIP endpoints both help a telephony system communicate over SIP, but they are not equivalent objects. A FreeSWITCH profile is primarily a SIP user-agent instance that binds signaling and applies a broad operating policy. An Asterisk PJSIP endpoint is primarily a profile for a remote phone, server, or service and is linked to separate objects for reachability, authentication, identification, registration, and transport. Comparing them as if they were two spellings of the same record leads to weak designs.

Why this distinction matters

A migration or architecture review often begins with a table that tries to map one configuration section directly to another. That can hide the real question: what responsibility does each object own? If a team treats every FreeSWITCH gateway as an Asterisk endpoint, or every PJSIP endpoint as a FreeSWITCH profile, it may combine trust boundaries, select the wrong inbound context, or misunderstand how a contact is found.

Use a responsibility map instead of a line-by-line translation. Identify who listens on which address and protocol, how an inbound request is associated with a trusted party, where credentials live, how the destination is located, which dialplan context receives a call, how outbound registration works, and which network or media policy applies.

What a FreeSWITCH SIP profile represents

FreeSWITCH commonly provides SIP through the Sofia module. A SIP profile creates a signaling domain with its own bind address, port, transport behavior, context, codec and media settings, NAT behavior, access controls, and other policy. A deployment may separate internal devices from external carriers with different profiles, although production topology should follow actual trust and network boundaries rather than merely copying a sample layout.

An inbound call arriving on a profile inherits relevant profile behavior, including the dialplan and context selected for that traffic unless another authorized mechanism overrides it. This makes profile placement a security and routing decision. Binding a profile broadly or choosing an overly permissive context can expose more service than intended.

Gateways are configured in relation to Sofia profiles. A gateway represents a remote SIP service such as a carrier and can hold registration and routing parameters. Directory users represent local identities and can provide credentials, variables, and parameters used when endpoints register or calls are processed. These objects work with a profile, but they do not turn every remote party into a separate listening profile.

What an Asterisk PJSIP endpoint represents

In Asterisk's res_pjsip model, an endpoint object describes SIP behavior for a remote party such as a telephone or server. It includes media and session policy and links to other configuration objects. An Address of Record, or AoR, tells Asterisk where that party can be contacted through one or more contacts. An auth object contains authentication policy and credentials. A transport defines how SIP is carried and where Asterisk binds.

Additional objects cover other responsibilities. An identify object can associate inbound requests with an endpoint using source network information. A registration object can make Asterisk register outbound to a provider. A contact may be created dynamically by a device registration or configured statically. The endpoint ties relevant pieces together, but it is not itself the listening socket, credential store, contact database, and outbound registration all at once.

This decomposition is flexible, but relationships must be reviewed. An endpoint generally needs an associated AoR to be contacted. Authentication used for inbound verification and authentication used toward an upstream service have different meanings and should not be casually reused. If endpoint identification is ambiguous, a request may match the wrong policy or fail before the dialplan.

A better conceptual mapping

A FreeSWITCH SIP profile maps more closely to a broad signaling listener and policy domain than to one Asterisk endpoint. Its nearest Asterisk counterpart is partly the transport plus global or endpoint policy, but the match is not exact. A FreeSWITCH gateway overlaps with several PJSIP concepts: endpoint behavior, an AoR or contact, authentication, optional identify rules, and sometimes outbound registration.

A FreeSWITCH directory user overlaps with a PJSIP endpoint, AoR, auth, and dynamic contact relationship for a registering telephone. The FreeSWITCH profile's context and the Asterisk endpoint's context both influence where inbound calls enter routing, but they are attached at different levels. Preserve the business intent rather than attempting mechanical conversion.

Example: an office telephone

For an office telephone in FreeSWITCH, the phone commonly registers through an internal Sofia profile. The directory supplies the user's identity and authentication data, plus variables such as the user's context. The profile supplies the listener and shared signaling policy. The dialplan later decides what the registered user may call.

In Asterisk PJSIP, the same telephone commonly has an endpoint object linked to an auth object and an AoR. When the phone registers, its contact becomes associated with the AoR. The endpoint's context controls the dialplan entry for calls from that device. One transport may be shared by many endpoints.

The business controls remain similar even though the objects differ: unique credentials, an appropriate dialing class, bounded registration lifetime, reachability monitoring where useful, supported codecs, and a tested NAT policy. The configuration review should demonstrate those outcomes, not merely count sections.

Example: a carrier trunk

A FreeSWITCH carrier is commonly represented by a gateway under a selected external or purpose-built profile. The gateway may register, or the provider may authenticate by IP. Outbound dialplan actions select the gateway. Inbound traffic enters through the profile and must be constrained to expected source networks and destinations.

In Asterisk PJSIP, a carrier design may use endpoint, AoR, auth, identify, registration, and transport objects in the combination required by the provider. An IP-authenticated provider may not need outbound registration or password authentication, but it still needs reliable endpoint identification and routing. A registering provider needs separate consideration of registration and request authentication.

Do not infer health from registration alone. Some trunks intentionally do not register. A provider can be registered while calls fail because of routing, number format, codec, or media issues. Conversely, an IP-authenticated trunk may be healthy without any registration state. Define service checks that match the actual contract.

Inbound identification is a trust decision

The system must decide which policy applies when a SIP request arrives. In FreeSWITCH, the receiving profile, directory lookup, gateway relationship, access lists, and channel variables influence that decision. In Asterisk, endpoint identification may use request information or an identify object associated with trusted source networks. The exact mechanism must match the provider or device behavior.

Never treat a caller-supplied display name or calling number as proof of identity. A source IP can also be insufficient when networks are shared or change without notice. Document what is authenticated, what is merely asserted, and what the business is allowed to display or use for authorization.

Transport, NAT, and media boundaries

SIP signaling and RTP media are related but separate. A phone can register and a call can answer while audio fails. In FreeSWITCH, profile settings influence SIP and advertised media addresses, NAT handling, and codec behavior. In Asterisk, transport and endpoint options combine with system networking and RTP configuration. Never copy public or private address settings without understanding the network path.

Document the bind address, advertised address, firewall policy, SIP transport, RTP range, and expected direction of every call leg. Test on the networks users actually use. One-way audio commonly indicates that signaling succeeded but one RTP direction is blocked or advertised incorrectly; changing authentication or dialplan rules will not repair that.

Reloads and change control

Not every signaling change is safely reloadable in every release. Listener, transport, or bind changes may require a restart, while user or routing changes may support narrower reloads. Confirm the installed version's behavior and plan the maintenance window accordingly. A command returning success does not prove that existing and new calls use the intended object.

Before a change, capture sanitized current state and a restorable configuration backup. After the change, confirm the relevant profile, transport, endpoint, gateway, registration, and contact state. Then place functional calls. Roll back when acceptance criteria fail rather than applying several speculative edits.

Security practices for both models

• Use unique secrets where password authentication is required and store them outside articles, chats, and AI prompts.
• Bind listeners only where needed and restrict carrier traffic to expected sources where the provider supports stable network ranges.
• Send each device or trunk into a least-privilege routing context.
• Do not trust caller-provided identity merely because a SIP request reached the server.
• Separate management and control interfaces from public signaling.
• Rate-limit and monitor failed authentication without exposing secret values in reports.

A safer migration method

Inventory the current system by function. For every phone and trunk, record ownership, authentication method, source identification, registration direction, contact discovery, transport, codec policy, routing context, caller-ID rules, NAT behavior, and failover expectations. Redact secrets from the working document.

Build target objects from that inventory. Do not translate names blindly. Test a single representative phone and trunk in isolation, then test inbound, outbound, transfer, hold, DTMF, voicemail or queue treatment, caller identity, and both audio directions. Validate rejected calls as well as successful calls. Only then migrate additional devices or numbers in controlled groups.

Operational evidence to collect

For endpoint problems, identify which listener received the request, how the remote party was matched, whether authentication succeeded, where its current contact points, and which context received the call. For trunk problems, confirm whether registration is actually required, whether the far end is reachable, what number format was sent, and how the provider responded. For audio problems, inspect negotiated session descriptions and RTP reachability on both legs.

Keep a sanitized known-good record for each major connection type. Include expected states, not passwords. After upgrades, repeat functional calls because parser success and object visibility do not prove the complete service.

Questions for an architecture review

• Which local address, port, and transport receives each traffic class?
• How is an inbound request associated with a phone or carrier?
• Where are contacts learned, and when do they expire?
• Is outbound registration required, optional, or inappropriate?
• Which context and outbound permissions apply?
• How are public signaling and media addresses advertised?
• Which states prove availability, and which require a real call?

Version and documentation caveat

Exact options, defaults, and reload behavior vary with release and packaging. Confirm them against the deployed version before implementation. Primary sources reviewed in September 2026 include the official FreeSWITCH chapter on SIP profiles with Sofia and the official Asterisk guide to PJSIP configuration sections and relationships.

Bottom line

A FreeSWITCH SIP profile defines a broad signaling and policy domain; gateways and directory users operate around it. An Asterisk PJSIP endpoint describes a remote party and links modular transport, location, authentication, identification, and registration objects. Design and migrate by responsibility, trust boundary, and tested call behavior. A one-row object mapping is simpler, but it is rarely accurate enough for production.