Source record · tier 2 current vendor documentation
Cisco Preferred Architecture for Webex Calling — Design Overview
- Publisher
- Cisco Systems, Inc. (CTG TME)
- URL
- https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
- Published
- 2025-08
- Updated
- unknown
- Accessed
- 2026-09-16
- HTTP status
- 200
- License
- Cisco proprietary documentation, all rights reserved; no-redistribution; short excerpts and locators only
Source notes citing this source
- A migration that concentrates many users into a single Webex Calling location served by 1 registration-based Local Gateway can reach the documented 250 concurrent call ceiling at peak, at which point Cisco states the limit is enforced and additional calls are rejected by the Webex Calling access session border controllers rather than by the carrier. inferred in context
- Cisco states that Webex Calling users can be set up to use Webex Calling services from within Microsoft Teams, and that the administrator selects the default calling application for the organisation while individual users may be configured to use other applications. in context
- Each Webex Calling customer is provisioned on one Webex Calling instance, all provisioning information for that customer is stored in that instance, and the SIP signalling of every endpoint and Local Gateway provisioned for that customer is tied to the instance the customer is provisioned on. in context
- Each Webex Calling data centre hosts the call routing functions and holds customer calling configuration data, and also hosts 2 tiers of session border controller: access SBCs that terminate all customer-facing SIP connections from Local Gateways endpoints and soft clients, and peering SBCs that terminate the SIP peering connections to SIP service providers. in context
- Cisco describes Dedicated Instance as an entitlement within Webex Calling that provides a Cisco Unified Communications Manager based stack of applications in a private cloud dedicated to a single customer. in context
- The Preferred Architecture design overview dated August 2025 lists the Webex Calling regions as the United States Canada Europe the United Kingdom Australia Japan and Saudi Arabia, and names no Indian region, while the data centre article dated 14 November 2025 lists Chennai and Mumbai among the data centres. in context
- Webex Edge Connect peers a customer's Webex meetings and Webex Calling traffic with an Equinix Cloud Exchange location to provide guaranteed bandwidth and quality of service, and Cisco offers it as the access connectivity option beyond over-the-top Internet. in context
- For an inter-region call the access session border controllers in both regions anchor the media, the traffic between those access SBCs traverses the global Webex backbone, and only the part of the media flow between the endpoints and their own region's access SBC traverses the Internet as the access network. in context
- Media flows involving a Local Gateway are always anchored on the access session border controllers of the region in which that Local Gateway is deployed. in context
- In Cisco's worked example of a call between 2 phones in Australia for a customer assigned to the United States region, the media path is kept on the access session border controllers in the Australia region under the control of the United States instance while the SIP signalling for the call goes back to the call control entity in the United States region, and Cisco describes that regional media path as the fallback that ICE optimization can replace with a direct path. in context
- Webex Calling uses SIP for signalling and SRTP for media, the Webex App and phones and registering Local Gateways initiate a TLS signalling connection to Webex Calling and are authenticated by it, and Webex Calling sends signalling traffic back over that same connection, which Cisco describes as providing simple firewall traversal; dynamic NAT can be used for IP phone and registration-based Local Gateway addresses. in context
- For over-the-top connections Cisco states that the network between Webex Calling and on-premises endpoints and Local Gateways should have at most 100 ms one-way latency, 10 ms packet jitter and 0.5 percent packet loss. in context
- Cisco states that the initial Webex Calling region selection cannot be changed later, that the decision should be taken early in a transition to avoid excessive signalling round-trip delay, and recommends selecting the Webex Calling instance that provides the lowest signalling round-trip times for the largest number of users in the deployment. in context
- The region selection for a Webex Calling customer determines the location of the authoritative call control entity for all of that customer's calls, and Cisco states that all Webex Calling call control entities can use access resources in each region so that media for calls anchored on the access layer need not cross to the customer's own region. in context
- Cisco states that Webex Calling supports video calls between video capable Cisco phones including the 8845 8865 and 8875, Webex Devices, and the Webex App on desktop and mobile when configured with Webex Calling for users. in context
- For calls resolving to Webex Calling, plus-prefixed E.164 patterns are evaluated first, then enterprise number patterns with no normalisation applied beforehand, and finally domain or URI patterns; where several patterns match, the most specific wins and range patterns using X are preferred over prefix patterns using the exclamation mark. in context
- Dial plan patterns must be unique across the organisation; the same pattern cannot exist in 2 different dial plans, which makes routing deterministic. in context
- Webex Calling dial plans are global to the enterprise and apply to all users regardless of location. in context
- A Webex Calling dial plan differentiates destinations bound for the on-premises Unified CM, which are sent as enterprise calls, from all other destinations, which are sent as PSTN calls, over the same trunk or route group. in context
- During coexistence a Local Gateway can simultaneously provide PSTN access and an interconnect to the existing on-premises call control, and the on-premises call control may remain in permanent use alongside Webex Calling. in context
- A certificate-based Local Gateway trunk supports up to 2000 concurrent calls over the internet, an order of magnitude more than the registration-based model. in context
- A location using a Local Gateway is subject to a default scale limit of 250 concurrent calls, which affects how locations should be sized and split; locations using Cloud Connected PSTN are not subject to that limit. in context
- Webex Calling does not support wildcard certificates on the Local Gateway, and only certificates carrying the server authentication extended key usage are accepted. in context
- Calls exceeding the registration-based Local Gateway concurrency ceiling are rejected by the Webex Calling access session border controller with a SIP 403 Forbidden response. in context
- A registration-based Local Gateway is limited to 250 concurrent calls per registering gateway, a ceiling attributed to TLS and TCP signalling performance. in context
- Webex Calling ignores the registration expiry value sent by the Local Gateway and enforces a value of 120 seconds, refreshing at approximately half that lifetime. in context
- Registration-based Local Gateway signalling is established outbound only from the enterprise to Webex Calling over SIP with TLS, so no inbound firewall rule is required. in context
- A maximum of 10000 dial plans may be configured per customer, and each dial plan may hold up to 10000 dial patterns. in context
- Changing a location from 1 PSTN type to another is partly self-service, partly a manual migration, and in a small number of combinations unsupported. in context
- Exactly 1 PSTN choice can be configured for each Webex Calling location. in context
- The PSTN provider used for a call depends only on the originating location of the Webex Calling call; no other attribute of the call affects PSTN selection, not even the called number. in context
- Rerouting to another trunk is triggered by SIP responses 401, 470, 480 and 606 when no provisional 18x response preceded them, by all other 4xx responses except 403, 404, 410, 413, 484 and 486, by all 5xx responses, and by a 12 second SIP timeout. in context
Cite this source record
APA
WarmTransfer. (n.d.). Cisco Preferred Architecture for Webex Calling — Design Overview. WarmTransfer. https://warmtransfer.net/knowledge/sources/cisco-pdf-preferred-architecture-webex-calling
BibTeX
@misc{warmtransfer-cisco-pdf-preferred-architecture-webex-calling,
title = {Cisco Preferred Architecture for Webex Calling — Design Overview},
author = {{WarmTransfer}},
year = {2025},
url = {https://warmtransfer.net/knowledge/sources/cisco-pdf-preferred-architecture-webex-calling},
note = {Cisco Systems, Inc. (CTG TME), accessed 2026-09-16}
}