sip media · published

SIP registration failures

Verified 2026-09-25 · 56 sources · tier 1–2 · 2 disputed

Disputed: 2 sources below carry conflicting evidence.

SIP registration binds an address-of-record to a user agent's current network location through an authenticated request-response transaction 1​36. WarmTransfer's reading of the sources is that when an endpoint cannot register, calls cannot be routed to or from that user agent until the underlying transaction, digest authentication, or transport failure is resolved 38​43.

Registration flows and authentication

In an RFC 3665 registration exchange, the initial REGISTER request is met with a 401 Unauthorized carrying a challenge; the client resends the REGISTER with credentials computed from that challenge, and the registrar accepts it with 200 OK 1. In the RFC 3665 registration example, the credentialed retry keeps the original Call-ID and increments CSeq from 1 to 2 10. The RFC 3665 contact-list update example shows updating an existing contact list being accepted with 200 OK without a new 401 challenge 51. In the RFC 3665 example, sending a REGISTER with no Contact header field queries the current bindings, returning 200 OK with the active registrations in Contact headers 36. Setting Contact to * with Expires equal to 0 cancels all active registrations for that user 50.

In the RFC 3665 unsuccessful registration example, the server responds to the credentialed REGISTER with another 401 Unauthorized if the provided password does not match the account 9. WarmTransfer's reading of the sources is that when a trace shows a second 401 or 407 response to a REGISTER that already contains an Authorization or Proxy-Authorization header, the credentials (such as username, password, or realm) were rejected rather than the initial challenge being missed 38.

RFC 8760 updates RFC 3261 digest authentication by permitting SHA-256 and SHA-512/256 18, while MD5 is kept only for backward compatibility with RFC 2617 and is marked NOT RECOMMENDED 24. A server may present multiple WWW-Authenticate or Proxy-Authenticate headers in order of preference, and the client should use the topmost algorithm it supports 25. Servers must also include a qop parameter in authentication challenges 35. WarmTransfer's reading of the sources is that if a registrar offers only SHA-256 challenges to a user agent supporting only MD5, the authentication exchange will likely fail through repeated challenges or an abandoned registration 8.

Transport, NAT, and timeouts

The first digit of a SIP Status-Code indicates the response class, such as 4xx for request failures, while the last 2 digits do not categorize the response 42. Under RFC 4320, sending a 408 response to a non-INVITE request arrives too late to be useful 5, and transaction-stateful elements are forbidden from generating 408 responses to non-INVITE requests 27. Additionally, RFC 4320 prohibits sending a 100 provisional response to non-INVITE requests over unreliable transports such as UDP before client Timer E reaches T2 28. WarmTransfer's reading of the sources is that an expired REGISTER transaction on an RFC 4320-compliant path appears on the wire as retransmissions without a final response, meaning any 408 seen by an administrator is typically generated locally by the endpoint's own transaction layer 43.

Behind NAT devices, standard SIP routes UDP responses to the source IP address but targets the port declared in the topmost Via header, which does not match the dynamic port allocated by NAT 52. RFC 3581 symmetric response routing resolves this by allowing clients to add an empty rport parameter to the top Via; when sending over UDP, the client must listen for the response on the same source IP and port it transmitted from 39. The server populates the client's actual source port into rport and transmits UDP responses back to that port and the received IP address 40. RFC 3581 notes that UDP NAT bindings are often short-lived, instructing clients to refresh NAT state by retransmitting an INVITE approximately every 20 seconds 26. WarmTransfer's reading of the sources is that when registration refresh or keep-alive intervals exceed the firewall's NAT binding duration, outbound registrations can continue to succeed while incoming requests directed to the registered contact fail 37.

RFC 5626 establishes outbound connections because endpoints behind NATs or firewalls are frequently unable to accept unsolicited inbound connections 31. Under RFC 5626, registrations identify the physical user agent using a +sip.instance URN across reboots, alongside a reg-id parameter to isolate distinct network flows 20. RFC 5626 registrars must support the Path header mechanism, signaled by the outbound option tag 32. Flow keep-alive intervals vary by transport:

  • For connection-oriented transports, RFC 5626 specifies CRLF keep-alives with a default upper bound of 120 seconds and a lower bound of 95 seconds 33.
  • For UDP flows, keep-alives utilize STUN Binding Requests transmitted at random intervals between 24 and 29 seconds 34.

A successful RFC 5626 registration response may include a Flow-Timer header specifying how many seconds the registrar will wait without keep-alives before declaring the flow dead 19. If a flow fails, the endpoint calculates a retry backoff capped at W = min(max-time, base-time * 2^consecutive-failures), where max-time defaults to 1800 seconds, and base-time is 30 seconds if all flows failed or 90 seconds if an alternate flow remains up 29. The endpoint then applies a uniform random delay between 50% and 100% of W before re-registering 30. WarmTransfer's reading of the sources is that an endpoint backing off under RFC 5626 rules can wait up to approximately 30 minutes before attempting to register again, meaning extended recovery times after network disruptions are expected protocol behavior rather than independent device failures 41.

Platform differences

Cisco Webex Calling

Cisco advises disabling SIP ALG or inspection mechanisms on edge firewalls and routers for Webex Calling, as ALGs can interfere with traffic traversal even when encrypted 53. Firewalls must maintain sufficient NAT binding lifetimes, taking into account that Cisco phones issue registration refreshes every 1 to 2 minutes 55. Furthermore, NAT and PAT pools must accommodate overlapping internal source ports by mapping them to unique external ports, avoiding strict source-port preservation 54. Webex Calling network requirements mandate port 8934 for registration-based trunks and port 5062 for certificate-based trunks 56.

For registration-based Cisco Local Gateways (LGW) on Cisco IOS XE, the tenant registrar configuration uses the sips scheme over TCP TLS, with an expires parameter of 240 seconds and a refresh-ratio of 50 23. The LGW configuration defines credentials for 2 realms—BroadWorks and the registrar domain—which are applied when the registrar issues a challenge 22. Registration is verified on the local gateway when a 200 OK response is received from the access SBC 21.

Cisco Unified Communications Manager and CME

On Cisco Unified Communications Manager (CUCM), endpoint registration proceeds through multiple sequential stages: obtaining an IP address via DHCP, downloading firmware and security trust files (CTL/ITL) via TFTP, downloading the configuration file, and finally transmitting the SIP REGISTER request 17. To diagnose EndPointUnregistered alarms in CUCM, administrators must correlate the alarm timestamp, device MAC address, and reason number against the system error message definitions 15.

Sources disagree regarding the default registration expiration interval for CUCM: Cisco tech note 212143 (2017) states that a phone sends an initial REGISTER with an Expires value of 120 seconds to its primary CUCM 13, whereas Cisco tech note 220670 (2023) illustrates a trace where the phone sends Expires: 3600 and CUCM responds with 200 OK setting Expires: 120 14. For secondary CUCM nodes, a phone sends keepalive REGISTER requests with an Expires value of 0 16.

On Cisco Unified Communications Manager Express (CUCME), registration failures can occur if the registrar server is disabled or if the endpoint does not match an active configuration pool, appearing in logs as "No pool match for the registration request" 12. CUCME registration events are investigated using the debug commands debug ccsip message, debug voice register error, and debug voice register event 11.

Twilio SIP Domains

Twilio SIP Domain registration enforces specific expiration bounds and credential mappings:

  • Twilio accepts registration expiration values between 600 seconds and 3600 seconds; requests with lower durations are rejected with 423 Interval Too Brief 47.
  • Registrations are capped at 10 active bindings per address-of-record; an 11th registration attempt for the same AOR is rejected 45.
  • The endpoint username in the REGISTER message must match a configured username in a Credential List assigned to the SIP Domain 48.
  • If an endpoint attempts registration against a SIP Domain that lacks an assigned Credential List, Twilio logs warning 32212 ("SIP: Registration Authentication problem") 46.

See also

Applicability

Applies to: SIP, Cisco Webex Calling, Cisco Webex Calling Local Gateway (IOS XE), Cisco Unified Communications Manager, Cisco Unified Communications Manager Express, and Twilio Programmable Voice SIP Domains. Deployments: on-premises, multi-tenant, and any. Sources checked 2026-09-25.

What remains uncertain

Vendor-specific meanings of Forbidden responses on REGISTER (such as disabled accounts, IP blocks, rate limits, or incorrect domains) are not covered by the sources below. Webex Calling device and third-party device registration error codes and troubleshooting are not covered by the sources below. SIP Gateway device registration failures are not covered by the sources below. SIP over TLS registration failures involving certificate trust, SNI, or cipher mismatches are not covered by the sources below. CUCM EndPointUnregistered and EndPointTransientConnection reason-code tables are not covered by the sources below. RFC 3263 DNS NAPTR/SRV registrar discovery failures are not covered by the sources below. Digest stale=true nonce handling and nonce reuse are not covered by the sources below. Poly and Yealink phone registration diagnostics and status strings are not covered by the sources below.

See also

Related to

  • SIP ALG problems on firewalls and routers — SIP ALG rewriting is one cause of registrations that succeed but then drop or cannot receive inbound requests; this packet cites only the Webex Calling port-reference recommendation and leaves ALG mechanics to that topic

Referenced by

  • Message waiting indicator troubleshooting — SIP-integrated voicemail ports must register with Unified CM before MWI NOTIFYs can flow; registration failures present as MWI failures. Topic exists in the corpus queue per the git status snapshot; not researched here.
  • Poly phones on Teams and Webex and Zoom — Poly provisioning failures (TLS 1.2 updater; DHCP option 160; factory reset prerequisites) overlap SIP registration troubleshooting.
  • Setting up FreePBX with a SIP trunk — Step 9 of the credential branch checks registration status; that topic covers diagnosing registration failures in general.
  • Yealink phones on UC platforms — Provisioning and redirection failures (RPS change; pre-2019 Yealink hardware on Zoom) surface as registration failures

Sources

  1. 1
    In the RFC 3665 successful registration example the first REGISTER is answered with 401 Unauthorized carrying a challenge, the UA resends REGISTER with credentials computed from that challenge, and the server then returns 200 OK.
    RFC 3665: Session Initiation Protocol (SIP) Basic Call Flow Examples · Section 2.1 Successful New Registration, messages F1-F4 · Checked 2026-09-25
  2. 2
    A registrar or UAS challenges with 401 Unauthorized and a WWW-Authenticate header, which the UA answers with Authorization; a proxy challenges with 407 Proxy Authentication Required and a Proxy-Authenticate header, which the UA answers with Proxy-Authorization.
    RFC 3261 — SIP: Session Initiation Protocol · Sections 22.2 (User-to-User Authentication) and 22.3 (Proxy-to-User Authentication) · Checked 2026-09-25
  3. 3
    RFC 3261 registrar processing returns 403 Forbidden when the authenticated user is not authorized to change registrations for the address-of-record in the REGISTER.
    RFC 3261 — SIP: Session Initiation Protocol · Section 10.3 Processing REGISTER Requests, authorization step · Checked 2026-09-25
  4. 4
    RFC 3261 registrar processing returns 404 Not Found when the address-of-record in the To header is not valid for the domain in the Request-URI.
    RFC 3261 — SIP: Session Initiation Protocol · Section 10.3 Processing REGISTER Requests, address-of-record step · Checked 2026-09-25
  5. 5
    RFC 4320 finds that a 408 response to a non-INVITE request always arrives too late to be useful.
    RFC 4320: Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Transaction · Section 2.2 Remove the useless late-response storm · Checked 2026-09-25
  6. 6
    RFC 3261 lets a registrar send 423 only when the requested interval is greater than zero, less than one hour and below the registrar's configured minimum.
    RFC 3261 — SIP: Session Initiation Protocol · Section 10.3 Processing REGISTER Requests, step 7 · Checked 2026-09-25
  7. 7
    A registrar may reject a REGISTER whose requested expiration is too short with 423 Interval Too Brief carrying a Min-Expires header, and the UA may retry with every contact's expiration set at or above the Min-Expires value.
    RFC 3261 — SIP: Session Initiation Protocol · Sections 10.2.8 (Error Responses) and 10.3 (Processing REGISTER Requests) · Checked 2026-09-25
  8. 8
    A registrar that offers only SHA-256 digest challenges to a UA that supports only MD5 will probably cause authentication to fail, which shows up as repeated challenges or an abandoned registration.inferred
    RFC 8760: The Session Initiation Protocol (SIP) Digest Access Authentication Scheme · multiple-challenge and UAC selection sentences · Checked 2026-09-25
  9. 9
    In the RFC 3665 unsuccessful registration example, a REGISTER carrying credentials is answered with another 401 Unauthorized because the password does not match the one set for the account.
    RFC 3665: Session Initiation Protocol (SIP) Basic Call Flow Examples · Section 2.5 Unsuccessful SIP Registration, response to F3 · Checked 2026-09-25
  10. 10
    In the RFC 3665 registration example the credentialed retry REGISTER keeps the same Call-ID as the challenged REGISTER and increments CSeq from 1 to 2.
    RFC 3665: Session Initiation Protocol (SIP) Basic Call Flow Examples · Section 2.1, messages F1 and F3 (Call-ID and CSeq header fields) · Checked 2026-09-25
  11. 11
    Cisco's CUCME registration troubleshooting uses debug ccsip message, debug voice register error and debug voice register event to capture and interpret SIP REGISTER exchanges.
    Troubleshoot IP Phone Registration Issues with CUCME · Step 4 (debug commands) · Checked 2026-09-25
  12. 12
    For SIP phones on CUCME, Cisco says to check that the registrar server is enabled and that a voice register pool matches the phone. A failed match is logged as 'No pool match for the registration request'.
    Troubleshoot IP Phone Registration Issues with CUCME · SIP phone troubleshooting steps (registrar server check; pool match failure reason) · Checked 2026-09-25
  13. 13
    Cisco tech note 212143 (2017) says the default Expires value in the REGISTER a phone sends to its primary CUCM is 120 seconds.disputed
  14. 14
    In the sample trace in Cisco tech note 220670 (2023), a SIP phone's REGISTER carries Expires: 3600 and CUCM's 200 OK carries Expires: 120, so the registrar sets the shorter refresh interval.disputed
    Troubleshoot IP Phone Unregistration Issues in CUCM · trace examples in the registration process walkthrough (REGISTER and 200 OK) · Checked 2026-09-25
  15. 15
    For CUCM EndPointUnregistered alarms, Cisco advises matching the alarm's reason number, MAC address and timestamp, and looking up reason codes in the system error message reference.
    Troubleshoot IP Phone Unregistration Issues in CUCM · section 'EndPointUnregistered System Error message explanation' · Checked 2026-09-25
  16. 16
    Cisco tech note 212143 says a phone's keepalive REGISTER to its secondary CUCM server has an Expires value of 0.
    General Information for CUCM IP Phone Registration/Deregistration Troubleshooting · Expires field paragraph (secondary CallManager sentence) · Checked 2026-09-25
  17. 17
    Cisco describes CUCM SIP phone registration as a series of stages: DHCP addressing, TFTP download of firmware and security files (CTL/ITL), configuration file retrieval, and only then SIP REGISTER to Unified CM.
    Troubleshoot IP Phone Unregistration Issues in CUCM · registration process overview section · Checked 2026-09-25
  18. 18
    RFC 8760 updates RFC 3261 to allow SHA-256 and SHA-512/256 in SIP digest authentication.
    RFC 8760: The Session Initiation Protocol (SIP) Digest Access Authentication Scheme · Abstract and header (Updates: 3261) · Checked 2026-09-25
  19. 19
    In RFC 5626, a Flow-Timer header in a successful registration response gives the number of seconds the server will wait without keep-alives before it may consider the flow dead.
    RFC 5626: Managing Client-Initiated Connections in the Session Initiation Protocol (SIP) · Section 4.4 Keep-Alives and Detecting Flow Failure · Checked 2026-09-25
  20. 20
    RFC 5626 registrations carry a +sip.instance Contact parameter, a URN that identifies the UA instance across reboots, and a reg-id parameter that keeps each flow's registration separate.
    RFC 5626: Managing Client-Initiated Connections in the Session Initiation Protocol (SIP) · Section 4.1 Instance-ID Selection; Section 4.2 Registrations · Checked 2026-09-25
  21. 21
    For a Webex Calling registration-based local gateway, Cisco counts registration as successful when a 200 OK is received from the access SBC.
    Configure Local Gateway on Cisco IOS XE for Webex Calling · registration-based trunk configuration, registration flow explanation · Checked 2026-09-25
  22. 22
    The same example configures authentication for two realms, BroadWorks and the registrar domain, and uses the username, password and realm from the credentials configuration when the registration is challenged.
    Configure Local Gateway on Cisco IOS XE for Webex Calling · registration-based trunk configuration, credentials and authentication commands and accompanying explanation · Checked 2026-09-25
  23. 23
    Cisco's registration-based local gateway example sets the tenant registrar with scheme sips, expires 240 and refresh-ratio 50 over TCP TLS.
    Configure Local Gateway on Cisco IOS XE for Webex Calling · registration-based trunk configuration, voice class tenant 100 'registrar' command · Checked 2026-09-25
  24. 25
    Under RFC 8760 a UAS may send several WWW-Authenticate or Proxy-Authenticate headers in order of preference, and a UAC seeing several for the same realm should use the topmost one it supports.
    RFC 8760: The Session Initiation Protocol (SIP) Digest Access Authentication Scheme · sentences beginning 'The UAS MUST add these header fields' and 'When the UAC receives a response with multiple WWW-Authenticate' · Checked 2026-09-25
  25. 26
    RFC 3581 tells clients to retransmit an INVITE about every 20 seconds, even after a provisional response, to keep the UDP NAT binding fresh. This shows the authors expected UDP NAT bindings to be short-lived.
  26. 27
    RFC 4320 forbids a transaction-stateful SIP element from sending a 408 response to a non-INVITE request.
  27. 28
    RFC 4320 forbids answering a non-INVITE request with 100 over an unreliable transport such as UDP before the client's Timer E would have reached T2.
  28. 29
    After a flow fails, RFC 5626 caps the wait before re-registering at W = min(max-time, base-time * 2^consecutive-failures), with max-time defaulting to 1800 s and base-time to 30 s if all flows failed or 90 s if at least one is still up.
  29. 30
    RFC 5626 has the UA wait a uniformly random time between 50% and 100% of the computed upper bound W before retrying.
  30. 31
    RFC 5626 exists because UAs behind NATs or firewalls often cannot accept inbound connections, so a server cannot reliably open a TCP connection or send unsolicited UDP to them.
  31. 32
    RFC 5626 requires registrars that implement it to support the Path header mechanism, and the outbound option tag tells the UA the registrar is compliant.
    RFC 5626: Managing Client-Initiated Connections in the Session Initiation Protocol (SIP) · Section 6 (Registrar Behavior) and Section 4.2.1 · Checked 2026-09-25
  32. 33
    For connection-oriented transports, RFC 5626 sets the default CRLF keep-alive upper bound at 120 seconds with a lower bound of 95 seconds.
    RFC 5626: Managing Client-Initiated Connections in the Session Initiation Protocol (SIP) · Section 4.4.1 Keep-Alive with CRLF · Checked 2026-09-25
  33. 34
    For UDP flows, RFC 5626 keep-alives are STUN Binding Requests sent at a random interval between 24 and 29 seconds.
    RFC 5626: Managing Client-Initiated Connections in the Session Initiation Protocol (SIP) · Section 4.4.2 Keep-Alive with STUN · Checked 2026-09-25
  34. 35
    RFC 8760 requires a UAS to always include a qop parameter in WWW-Authenticate and Proxy-Authenticate header values.
    RFC 8760: The Session Initiation Protocol (SIP) Digest Access Authentication Scheme · sentence beginning 'A UAS MUST always send a "qop" parameter' · Checked 2026-09-25
  35. 36
    A REGISTER with no Contact header field is a query; in the RFC 3665 example the server answers with 200 OK listing the current registrations in Contact header fields.
    RFC 3665: Session Initiation Protocol (SIP) Basic Call Flow Examples · Section 2.3 Request for Current Contact List · Checked 2026-09-25
  36. 37
    If a UA's registration refresh or keep-alive interval is longer than the NAT or firewall binding timeout, REGISTER can keep succeeding while inbound requests to the registered contact fail between refreshes.inferred
    RFC 5626: Managing Client-Initiated Connections in the Session Initiation Protocol (SIP) · Section 3 Overview (UAs behind NAT cannot receive inbound connections); Section 4.4 keep-alives · Checked 2026-09-25
  37. 38
    When a trace shows a second 401 or 407 in reply to a REGISTER that already carries Authorization or Proxy-Authorization, the likeliest reading is that the credentials (username, password or realm) were rejected, not that the first challenge went unanswered.inferred
    RFC 3665: Session Initiation Protocol (SIP) Basic Call Flow Examples · Section 2.5 compared with Section 2.1 · Checked 2026-09-25
  38. 39
    A client may add an rport parameter with no value to the top Via, and when it sends over UDP it must be ready to receive the response on the same IP address and port it sent from.
  39. 40
    A server receiving a Via with an empty rport must fill in the request's source port, and for UDP it must send the response to the IP in the received parameter and the port in rport.
  40. 41
    A UA that implements RFC 5626 backoff can legitimately wait many minutes, up to about 30, before re-registering after repeated failures, so slow recovery after an outage is not necessarily a separate fault.inferred
  41. 42
    The first digit of a SIP Status-Code gives the response class (for example 4xx is a request failure), and the last two digits carry no categorisation role.
    RFC 3261 — SIP: Session Initiation Protocol · Section 7.2 Responses · Checked 2026-09-25
  42. 43
    On the wire, a REGISTER timeout in an RFC 4320-compliant path usually shows as repeated REGISTER retransmissions with no final response, and any 408 a phone reports is probably generated locally by its own transaction layer rather than received.inferred
  43. 44
    Under RFC 3261 a non-INVITE client transaction such as REGISTER over UDP retransmits on Timer E, which starts at T1 (500 ms default) and doubles up to T2 (4 s), and gives up when Timer F fires at 64*T1 (32 s by default).
    RFC 3261 — SIP: Session Initiation Protocol · Section 17.1.2.2 Formal Description (non-INVITE client transaction) and Table 4 · Checked 2026-09-25
  44. 45
    Twilio allows at most 10 active registrations per address-of-record and rejects the 11th active registration attempt for that AOR.
    SIP registration · registration limits paragraph · Checked 2026-09-25
  45. 46
    Twilio logs warning 32212 'SIP: Registration Authentication problem' when an endpoint tries to register to a SIP Domain with no Credential List mapped for registration, and the fix is to map one.
    32212: SIP: Registration Authentication problem · Possible Cause and Possible Solution fields · Checked 2026-09-25
  46. 47
    Twilio SIP Domain registration accepts expiration values from 600 seconds to 3600 seconds and rejects lower values with 423 Interval Too Brief.
    SIP registration · Registration expiration section · Checked 2026-09-25
  47. 48
    Twilio authenticates REGISTER against the Credential Lists mapped to the SIP Domain, and the endpoint's username must exactly match a username in one of those lists.
    SIP registration · registration authentication paragraph · Checked 2026-09-25
  48. 49
    RFC 3261 requires a request larger than 1300 bytes, or within 200 bytes of the path MTU, to be sent over a congestion-controlled transport such as TCP rather than UDP.
    RFC 3261 — SIP: Session Initiation Protocol · Section 18.1.1 Sending Requests · Checked 2026-09-25
  49. 50
    Cancelling all of a user's registrations uses a REGISTER with Contact: * and Expires: 0, and the server responds 200 OK after clearing the contact list.
    RFC 3665: Session Initiation Protocol (SIP) Basic Call Flow Examples · Section 2.4 Cancellation of Registration · Checked 2026-09-25
  50. 51
    The RFC 3665 contact-list update example shows an authenticated REGISTER being accepted with 200 OK without a new 401 challenge.
    RFC 3665: Session Initiation Protocol (SIP) Basic Call Flow Examples · Section 2.2 Update of Contact List · Checked 2026-09-25
  51. 52
    Without RFC 3581, SIP returns UDP responses to the request's source address but to the port written in the top Via, and behind a NAT that port is not the one the NAT binding opened.
    RFC 3581: An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing · Introduction (problem statement sentence beginning 'responses to requests are returned to the source address') · Checked 2026-09-25
  52. 53
    Cisco recommends turning off SIP ALG or similar SIP-aware functions on routers and firewalls for Webex Calling, because some ALG implementations cause firewall-traversal problems even though the traffic is encrypted.
    Port Reference Information for Webex Calling · section 'SIP Application Layer Gateway' · Checked 2026-09-25
  53. 54
    For Webex Calling behind NAT or PAT, Cisco says to size the NAT pool, make sure the NAT device can translate overlapping source ports to unique ports, and avoid strict source-port preservation.
    Port Reference Information for Webex Calling · section 'Network Address Translation (NAT)' · Checked 2026-09-25
  54. 55
    The Webex Calling port reference asks administrators to set a minimum NAT timeout for devices, noting that Cisco phones send a follow-up REGISTER refresh every 1-2 minutes.
    Port Reference Information for Webex Calling · section 'Network Address Translation (NAT)' · Checked 2026-09-25
  55. 56
    The Webex Calling port reference lists port 8934 as required for registration-based trunks and port 5062 for certificate-based trunks.
    Port Reference Information for Webex Calling · section 'IP Subnets for Webex Calling services', connection purpose table note · Checked 2026-09-25

Documents

tier 1 standards and regulators

RFC 3261 — SIP: Session Initiation Protocol

IETF / RFC Editor · 2002-06 · accessed 2026-09-04

tier 1 standards and regulators

RFC 3581: An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing

IETF / RFC Editor · 2003-08-01 · accessed 2026-09-25

tier 1 standards and regulators

RFC 3665: Session Initiation Protocol (SIP) Basic Call Flow Examples

RFC Editor / IETF · 2003-12-01 · accessed 2026-09-23

tier 1 standards and regulators

RFC 4320: Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Transaction

RFC Editor / IETF · 2006-01-01 · accessed 2026-09-25

tier 1 standards and regulators

RFC 5626: Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)

IETF / RFC Editor · 2009-10-01 · accessed 2026-09-24

tier 1 standards and regulators

RFC 8760: The Session Initiation Protocol (SIP) Digest Access Authentication Scheme

RFC Editor / IETF · 2020-03-01 · accessed 2026-09-25

tier 2 current vendor documentation

32212: SIP: Registration Authentication problem

Twilio · accessed 2026-09-25

tier 2 current vendor documentation

Configure Local Gateway on Cisco IOS XE for Webex Calling

Cisco Systems, Inc. (Webex Help Center) · 2026-07-09 · accessed 2026-09-04

tier 2 current vendor documentation

General Information for CUCM IP Phone Registration/Deregistration Troubleshooting

Cisco Systems · 2017-09-22 · accessed 2026-09-24

tier 2 current vendor documentation

Port Reference Information for Webex Calling

Cisco Systems, Inc. (help.webex.com) · 2026-09-08 · accessed 2026-09-16

tier 2 current vendor documentation

SIP registration

Twilio · 2026-08-19 · accessed 2026-09-25

tier 2 current vendor documentation

Troubleshoot IP Phone Registration Issues with CUCME

Cisco · 2018-11-23 · accessed 2026-09-25

tier 2 current vendor documentation

Troubleshoot IP Phone Unregistration Issues in CUCM

Cisco · 2023-07-28 · accessed 2026-09-24

Cite this page

APA

WarmTransfer. (2026, September 25). SIP registration failures. WarmTransfer. https://warmtransfer.net/knowledge/sip-registration-failures

BibTeX

@misc{warmtransfer-sip-registration-failures,
  title  = {SIP registration failures},
  author = {{WarmTransfer}},
  year   = {2026},
  url    = {https://warmtransfer.net/knowledge/sip-registration-failures},
  note   = {Verified 2026-09-25}
}