Choose registration or peering from the current order
SIPcity documents credential registration and static-IP peering as separate connection methods. Registration uses a SIP identity and password; peering trusts a stable public address and disables registration in the reviewed 3CX example. Record the enabled portal mode, assigned numbers, PBX or SBC, public address, transport and rollback owner before building a template.
Do not combine source-IP trust with credentials unless the current provider-issued design explicitly requires both. A portal login, whitelisted address, successful REGISTER or OPTIONS reply does not prove inbound routing, outbound authorization, caller identity or media.
Documented service facts
Reviewed 2026-10-13. Compare SIP trunk services →
SIP authentication
DocumentedSIPcity documents two distinct connection models: number-based username and password for registration, or a stable public source address whitelisted for static-IP peering. Peering leaves authentication fields blank in the reviewed 3CX example. Record the enabled portal mode, issued identity, expected source, transport and observed decision; do not combine credentials and IP trust or treat the account login as a SIP credential.
SIP registration
DocumentedThe generic record uses call.sipcity.com.au, the SIPcity number as username and authentication ID, registration enabled and calls without registration disabled. It publishes TLS 5061, while the broader methods page also lists UDP 5060 and a 180-second server expiry. A separate 3CX example says sip.sipcity.com.au or the hostname provided with the order. Preserve the account-issued host and loaded PBX state instead of silently normalizing these examples.
Inbound delivery and number format
DocumentedSIPcity says ordered or ported numbers can be routed in its portal. Its 3CX peering example adds DIDs exactly as issued, while the porting page says an active registered PBX or SIP peer receives incoming calls automatically at cutover. Those pages do not prove the selected number, Request-URI, identity headers or final PBX match. Retain the number order or port record and one timestamped authorized inbound trace.
Peering failover
DocumentedThe 3CX guide permits a primary public IP and an optional failover IP in SIPcity peering preferences. The reviewed material does not define health checks, retry responses, detection or restoration timers, route priority, established-call survival or whether the alternate is used for every failure mode. Bind continuity claims to the saved portal state and a provider-approved new-call failure and recovery exercise.
Numbers and service area
DocumentedThe trunk page includes one local number and supports ordering or porting numbers through the self-service portal. SIPcity also publishes Australian local, 1300 and 1800 porting categories. Catalogue and porting pages do not establish current inventory, portability, local-presence rules, activation time or caller-ID rights for a particular number. Preserve a dated eligibility result and order for the exact legal entity and service address.
Audio codecs, RTP and DTMF
DocumentedThe network page publishes G.711 A-law, G.711 mu-law, G.722, GSM and G.729, RFC 2833 or RFC 4733 DTMF, 20 ms packetization, E.164 dial strings, named RTP source addresses and a provider range of UDP 30000–40000. That is a published interface description, not evidence of the codec, address, payload or digit result negotiated by one PBX. Preserve both SDP bodies and decoded authorized-call evidence.
Fax and T.38
DocumentedSIPcity publishes fax.sipcity.com.au, a T.38 port range of 4000–6000 and separate Virtual Fax material in its help catalogue. Those references do not establish T.38 entitlement, switchover, redundancy, gateway interoperability or page limits on the selected voice trunk. Confirm the ordered fax workflow and qualify it independently from ordinary audio calls.
Signaling and media protection
DocumentedThe network page lists TLS signaling and SRTP media as supported protocols. The reviewed 3CX static-peering example instead uses UDP 5060 with SRTP disabled, while the generic registration page specifies TLS 5061. These are different profiles, not proof of end-to-end protection or universal availability. Record the ordered method, certificate validation, negotiated media profile and every unprotected hop.
Concurrent calls and call starts
DocumentedThe current trunk page includes one channel. SIPcity explains that one channel represents one concurrent call and says the trunk has no fixed channel maximum, while access bandwidth constrains use and it offers an approximate bandwidth planning figure. These statements do not establish the selected account entitlement, purchasable ceiling, calls-per-second limit, burst policy or a measured load result. Keep ordered channels, attempted starts, access capacity and PBX limits separate.
Australian 000 calling
DocumentedSIPcity’s current terms say Australian 000 calls are supported and require a Registered Location supplied to the IPND manager; the address can be changed in the account. The same terms warn that loss of power or broadband prevents the service and 000 dialing. Confirm the selected service, number-to-location record, callback identity, user instructions and an accessible independent calling method; never place an uncoordinated emergency test call.
Pricing and billing
Not verifiedThe trunk page identifies included components but the reviewed public page does not expose a complete current SIP-trunk price for one account. SIPcity publishes port submission, rejection, reversal and emergency-return charges separately, and its billing guide describes prepaid usage, monthly debits, top-ups and low-balance alerts. Use a dated order for the plan, extra channels, numbers, porting, usage, international destinations, hardware, taxes, term and cancellation.
Administration and support
DocumentedSIPcity documents self-service number ordering, porting and routing, peering preferences, account balance, payment methods, top-ups, low-balance notifications and transaction history. Those controls do not prove the selected administrator roles, maintenance notice, support response, monitoring boundary or restoration result. Preserve named owners, portal changes, current support contacts and timestamped service evidence.
SMS and MMS
Not verifiedSIPcity publishes app-based team messaging elsewhere in its portfolio, but the reviewed SIP-trunk and number pages do not establish SMS or MMS eligibility on trunk numbers, sender registration, API or webhook access, throughput, retention or price. Treat messaging as a separate product, number and compliance workflow.
Preserve the issued host instead of merging examples
The generic registration pages publish call.sipcity.com.au, the number as username and authentication ID, registration enabled and a 180-second server expiry. A separate 3CX guide says sip.sipcity.com.au or the registrar provided with the order. Keep that difference visible: the current welcome record and observed DNS and signaling state decide what belongs in the PBX.
Retain the loaded object, resolver output, transport, source and destination, From, To, Request-URI, authorization identity, challenge, Contact, expiry and result without exposing the password. Troubleshoot the exact method rather than copying an unrelated handset or PBX example.
Bind each DID and port cutover to an observed route
SIPcity’s 3CX example adds DIDs exactly as issued. Its porting page says an already active registered PBX or SIP peer receives incoming calls at cutover; otherwise calls may reach generic voicemail until routing is known. Preserve the number, port category, scheduled window, trunk number or peer address, portal destination and rollback contact.
After cutover, correlate a timestamped non-emergency call from the provider-delivered Request-URI and identity headers to the first matching PBX rule and final destination. The public page also says reversal or emergency-return requests have a four-hour window and may not always be available, so do not treat rollback as guaranteed.
Apply network settings to the selected profile
SIPcity publishes signaling transports, peer and firewall addresses, RTP sources and range, codecs, DTMF methods, packetization and E.164 dialing. The 3CX peering example uses UDP with SRTP disabled, while generic registration specifies TLS. Those records describe different profiles.
For authorized calls, preserve both SDP bodies, connection addresses, ports, payload mappings, DTMF events, decoded audio, signaling transport and negotiated media protection. Do not open broad firewall ranges, claim encryption or infer PBX compatibility merely because a protocol appears on a capability page.
Separate optional failover from a proven continuity result
SIPcity allows an optional failover IP alongside the primary peering address, but the reviewed material does not define the health decision, retry responses, timer, priority, established-call behavior or restoration sequence. Record both addresses, upstream and power dependencies, alternate capacity and the current portal state.
Use a provider-approved window to exercise a new-call failure, alternate delivery and return to primary. Keep that result separate from active-call survival, DNS behavior, registration recovery and the four-hour port-reversal workflow.
Reconcile channels, billing and 000 before acceptance
The trunk page includes one channel, while the channel explainer discusses additional concurrency and bandwidth. Preserve the signed channel entitlement, any call-start controls, usage rates, numbers, porting charges, prepaid balance rules, top-up settings, taxes and cancellation terms; public included-component language is not a complete quote or a load result.
SIPcity’s terms say Australian 000 is supported only with a Registered Location and warn that power or broadband failure prevents emergency dialing. Confirm each number-to-location mapping, user guidance and an accessible independent calling method. Follow a provider-approved validation procedure and never place an uncoordinated emergency call.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- SIPcity SIP Trunking ↗
- SIPcity registration and peering explained ↗
- SIPcity generic SIP registration configuration ↗
- SIPcity 3CX configuration ↗
- SIPcity network ports and IPs ↗
- SIPcity number porting ↗
- SIPcity channel explanation ↗
- SIPcity billing and payments ↗
- SIPcity master service agreement ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.