Separate the SIP identity from the account login
Localphone documents a SIP ID and SIP password in the Internet Phone dashboard and says these are not the same as the main account credentials. Record the issued SIP identity, registrar, endpoint or PBX owner and password-rotation process without exposing secrets. A successful account login does not prove SIP registration, and a successful registration does not prove inbound delivery, outbound authorization or media.
Preserve the loaded registration object, DNS result, source and destination, transport, From, To, Request-URI, authentication username, Contact, expiry, challenge and final response. Correlate by time and Call-ID rather than interpreting a dashboard status alone.
Documented service facts
Reviewed 2026-10-14. Compare SIP trunk services →
SIP authentication
DocumentedLocalphone documents a SIP ID and SIP password in the Internet Phone dashboard and distinguishes those credentials from the main account sign-in. Use the issued SIP identity only in the endpoint or PBX profile, keep the account login separate, and retain one redacted credential-rotation record and resulting challenge response.
SIP registration
DocumentedThe reviewed device guides use registration to localphone.com with the issued SIP ID and password. The Asterisk page is an older chan_sip example, not a current PJSIP template or compatibility statement. Preserve the dashboard-issued details, loaded PBX object, resolver result, Contact, expiry, challenge and response rather than translating the example silently.
Incoming-number delivery
DocumentedLocalphone documents incoming numbers that can be routed to an Internet Phone SIP ID or voicemail. It also says the number is assigned rather than selected from a public list and that sequential requests may require support. Those pages do not establish current inventory, the delivered Request-URI or identity headers, portability, or the first PBX match. Preserve the order, dashboard route and one authorized inbound trace.
Failover and continuity
Not verifiedThe reviewed public Localphone pages do not define redundant registrars, DNS failover behavior, retry timers, alternate delivery, restoration order or established-call survival. Treat registration recovery, inbound rerouting and user fallback as separate controls and qualify them only with account-specific provider evidence and an approved exercise.
Numbers and service area
Not verifiedThe Incoming Numbers support page explains assignment and routing but does not prove current inventory, local-presence rules, portability, activation time or entitlement for a particular legal entity and service address. Use a dated eligibility and order record for the exact country, number type and customer.
Audio codecs and DTMF
DocumentedThe older Asterisk example allows G.711 A-law and mu-law and specifies RFC 2833 DTMF. Device examples are configuration guidance, not proof of the codec, payload mapping, digit result, NAT path or media protection negotiated by a current account. Preserve both SDP bodies and decoded evidence from an authorized call.
Fax and T.38
Not verifiedThe reviewed Internet Phone, Incoming Numbers and device pages do not establish fax support, T.38 entitlement, audio-fax policy, switchover behavior, gateway interoperability or page limits. Qualify fax separately with current written service evidence and a representative approved test.
Signaling and media protection
Not verifiedThe reviewed public device guides do not establish TLS signaling, certificate validation, SRTP media, keying, supported cipher profiles or protected delivery across every hop. Do not infer encryption from account authentication. Record the negotiated signaling and media profile and every unprotected segment before making a protection claim.
Concurrent calls and call starts
Not verifiedThe reviewed public pages do not define account-level concurrent-call entitlement, calls-per-second limits, burst policy, inbound and outbound pooling or a supported deployment ceiling. Keep ordered capacity, access bandwidth, PBX limits and measured results separate.
Emergency calling
DocumentedLocalphone states that its Internet Phone service does not support emergency-service numbers and is not a complete replacement for a landline. Provide an accessible independent emergency-calling method, document the limitation for users and never place an uncoordinated emergency test call.
Pricing and billing
Not verifiedNo current price is reproduced here. The reviewed support material does not provide a complete dated quote for one account, number, destination mix, usage, taxes, minimum spend, credit policy, term or cancellation. Use the signed order and current account-specific tariff instead of a historical support-page amount.
Administration and support
DocumentedLocalphone documents Internet Phone details and SIP-password access through the dashboard, incoming-number routing controls, and a Help Centre support path. Those controls do not prove role separation, maintenance notice, response time, monitoring ownership or restoration performance. Preserve named owners, portal changes, current contacts and timestamped service evidence.
SMS and MMS
Not verifiedThe reviewed Internet Phone and Incoming Numbers pages do not establish SMS or MMS eligibility, sender identity, API or webhook access, throughput, retention, country coverage, compliance workflow or price. Treat messaging as a separate product and number qualification.
Treat the Asterisk page as an older example
The Localphone Asterisk guide uses chan_sip-era configuration and the localphone.com registrar. That is useful evidence of the service model, but it is not a current PJSIP template, supported-version statement or proof that copied defaults match a deployed PBX. Translate each required field explicitly into the supported driver and retain the current dashboard-issued values.
Keep registration authentication, endpoint identification, outbound caller identity, codec policy and DTMF handling separate. Validate the loaded configuration and one authorized call in each required direction instead of relying on config-file syntax alone.
Bind each incoming number to its dashboard route
Localphone says an incoming number can route to an Internet Phone SIP ID or voicemail. It also says customers are assigned a number rather than choosing one from a public list and may contact support about sequential numbers. Preserve the exact order, assigned number, dashboard destination, activation record and rollback owner.
For an authorized call, retain the provider-delivered Request-URI and identity headers, first matching PBX rule and final destination. Do not infer current inventory, portability, presentation format or sequential availability from a general support page.
Keep caller-ID rights separate from signaling fields
The Incoming Numbers page says an outgoing caller ID may be hidden or set to one of the account’s incoming numbers. That describes an account control, not permission to present any From or P-Asserted-Identity value. Save the verified number, dashboard selection, legal right and observed provider result for each call path.
If a call is rejected or rewritten, compare the dialed destination, From, P-Asserted-Identity, Remote-Party-ID where present, account selection and response. Do not work around provider identity enforcement by inserting an unverified number.
Observe codecs and DTMF on the actual path
The older Asterisk example names G.711 A-law and mu-law and RFC 2833 DTMF. Those settings are not a current entitlement or negotiated-call result. Preserve both SDP offers and answers, connection addresses, ports, payload mappings, telephone-event details, decoded audio and digit evidence for an authorized call.
Do not infer TLS or SRTP, fax behavior, NAT traversal, transcoding or compatibility from the device examples. Keep each unverified capability unresolved until current provider and observed path evidence agree.
Design around the emergency-service exclusion
Localphone states that Internet Phone does not support emergency-service numbers and is not a complete replacement for a landline. Treat that as an acceptance constraint: provide an accessible independent calling method, document it for every affected user and location, and include power, access-network and device failure in continuity planning.
Do not place an uncoordinated emergency call. Before production acceptance, also obtain current account-specific evidence for capacity, failover, service coverage, fax, protection, messaging, price, support and restoration; the public help pages do not close those questions.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Localphone Internet Phone support ↗
- Localphone Asterisk configuration ↗
- Localphone Incoming Numbers support ↗
- Localphone Bria configuration ↗
- Localphone Linksys PAP2 configuration ↗
- Localphone Linksys SPA2102 configuration ↗
- Localphone Help Centre ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.