9.6 Webex Calling Local Gateway (LGW) Architecture & Configuration

9.6 Webex Calling Local Gateway (LGW) Architecture & Configuration

A Webex Calling Local Gateway (LGW) is a Cisco Unified Border Element (CUBE) on Cisco IOS XE that connects the Webex Calling cloud to equipment on the customer's premises. Exam questions on blueprint objectives 4.1 ("Configure voice gateway and session border controller elements for on-premises and cloud calling") and 5.4.e (trunks and route groups) expect you to know the two trunk types, what Control Hub supplies, and how the CUBE configuration fits together.

---

1. What a Local Gateway Does

A Local Gateway has two jobs, and one router can do both:

1. Premises-based PSTN: A Webex Calling location whose PSTN connection is "Premises-based PSTN" sends and receives PSTN calls through an LGW trunk (or a route group of trunks). The gateway then reaches the carrier over an ITSP SIP trunk or an ISDN PRI. Organizations use this to keep existing carrier contracts, to support countries where Cisco Calling Plans and certified providers are not available, or to meet rules such as India's, where Webex Calling must use a local gateway for PSTN access.
2. PBX interworking: During a migration, the LGW connects Webex Calling to an on-premises PBX such as Cisco Unified CM, so cloud users and on-premises users can call each other by extension through dial plans (Section 9.2) without touching the PSTN.

Supported platforms include Cisco ISR 4000 and Catalyst 8000 Edge routers (8200, 8300, 8500) and the virtual Catalyst 8000V. A registration-based trunk needs IOS XE 17.6.1a or later; a certificate-based trunk needs IOS XE 17.9.1a or later.

---

2. The Two Trunk Types

Registration-based trunks are the simplest choice for most sites because nothing on the internet has to reach the gateway. Certificate-based trunks suit designs that need a peer-to-peer trunk with mutual authentication; Webex for Government supports only the certificate-based type.

---

3. Control Hub Tasks

1. Create the trunk under Calling > Call Routing > Trunk, in the location that owns it, and choose the trunk type. For a registering trunk, Control Hub then shows the registrar domain, the trunk group OTG/DTG value, the Line/Port, the outbound proxy address, and the username and password; you copy these into the CUBE configuration.
2. Assign the PSTN connection: Set the location's PSTN connection to Premises-based PSTN and choose the trunk or a route group.
3. Add routing for a PBX, if needed: put the trunk in a route group and reference it from a dial plan whose patterns cover the PBX numbers.
4. Check the status: The trunk list shows each trunk as online, offline, impaired, or unknown, refreshed every few minutes.

---

4. CUBE Configuration for a Registration-Based Trunk

The following blocks follow Cisco's published Local Gateway configuration. Values such as the registrar and the dtg come from the Control Hub trunk page.

Trust and TLS

crypto pki trustpoint EmptyTP
 revocation-check none
!
sip-ua
 timers connection establish tls 5
 transport tcp tls v1.2
 crypto signaling default trustpoint EmptyTP cn-san-validate server
 tcp-retry 1000
!
crypto pki trustpool import clean url https://www.cisco.com/security/pki/trs/ios_core.p7b

• The placeholder trustpoint has no certificate; it only lets CUBE run TLS. A registration-based trunk does not need a certificate on CUBE.
• crypto pki trustpool import clean installs Cisco's root CA bundle, which includes the IdenTrust Commercial Root CA 1 certificate used by Webex Calling, so CUBE can validate the Webex servers.
• cn-san-validate server makes CUBE check that the certificate Webex presents matches the host name CUBE connected to.

Global voice settings

voice service voip
 ip address trusted list
  ipv4 x.x.x.x y.y.y.y
 mode border-element
 media statistics
 media bulk-stats
 allow-connections sip to sip
 no supplementary-service sip refer
 stun
  stun flowdata agent-id 1 boot-count 4
  stun flowdata shared-secret 0 <shared-secret>
 sip
  asymmetric payload full
  early-offer forced

The trusted list must include the Webex Calling address ranges and your ITSP or PBX, because CUBE's toll-fraud check rejects SIP from untrusted sources. no supplementary-service sip refer makes CUBE handle transfers itself instead of passing REFER between the legs.

Codec, SRTP, ICE, and URI matching

voice class codec 100
 codec preference 1 g711ulaw
 codec preference 2 g711alaw
!
voice class srtp-crypto 100
 crypto 1 AES_CM_128_HMAC_SHA1_80
!
voice class stun-usage 100
 stun usage firewall-traversal flowdata
 stun usage ice lite
!
voice class uri 100 sip
 pattern dtg=dallas1463285401_lgu

• Cisco's base design allows only G.711 on both trunks; more codecs (or DSP transcoding) can be added if both sides support them.
• Media toward Webex Calling is always SRTP.
• stun usage ice lite enables ICE-Lite so Webex Calling can optimize media, sending it directly between the gateway and endpoints when the call does not need cloud services such as recording.
• The URI class matches the dtg= parameter that Webex Calling puts in the Request-URI of every call it sends to this trunk.

The tenant and the Webex trunk dial peer

voice class tenant 100
 registrar dns:98027369.us10.bcld.webex.com scheme sips expires 240 refresh-ratio 50 tcp tls
 credentials number Dallas1171197921_LGU username Dallas1463285401_LGU password 0 <password> realm BroadWorks
 authentication username Dallas1463285401_LGU password 0 <password> realm BroadWorks
 authentication username Dallas1463285401_LGU password 0 <password> realm 98027369.us10.bcld.webex.com
 no remote-party-id
 sip-server dns:98027369.us10.bcld.webex.com
 connection-reuse
 srtp-crypto 100
 session transport tcp tls
 url sips
 error-passthru
 asserted-id pai
 bind control source-interface GigabitEthernet0/0/1
 bind media source-interface GigabitEthernet0/0/1
 outbound-proxy dns:dfw04.sipconnect-us.bcld.webex.com
 privacy-policy passthru
!
dial-peer voice 100 voip
 description Inbound/Outbound Webex Calling
 max-conn 250
 destination-pattern BAD.BAD
 session protocol sipv2
 session target sip-server
 incoming uri request 100
 voice-class codec 100
 dtmf-relay rtp-nte
 voice-class stun-usage 100
 no voice-class sip localhost
 voice-class sip tenant 100
 srtp
 no vad

• The tenant holds everything specific to this trunk: the registrar, the credentials (Line/Port, username, password), the outbound proxy, TLS transport, SRTP crypto, and the interfaces to bind. The dial peer inherits it through voice-class sip tenant 100.
• session target sip-server sends outbound calls to the sip-server defined in the tenant.
• incoming uri request 100 selects this dial peer for calls from Webex by matching the dtg in the Request-URI. URI matching is evaluated before number matching (Section 7.1), so these calls cannot land on another dial peer by accident.
• destination-pattern BAD.BAD is a deliberate placeholder: the dial peer is never chosen by number. Calls reach it through dial-peer groups.

Routing between Webex Calling and the PSTN

dial-peer voice 200 voip
 description Inbound/Outbound IP PSTN trunk
 destination-pattern BAD.BAD
 session protocol sipv2
 session target ipv4:192.168.80.13
 incoming uri via 200
 voice-class sip asserted-id pai
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 voice-class codec 100
 dtmf-relay rtp-nte
 no vad
!
voice class uri 200 sip
 host ipv4:192.168.80.13
!
voice class dpg 100
 description Route calls to Webex Calling
 dial-peer 100
voice class dpg 200
 description Route calls to PSTN
 dial-peer 200
!
dial-peer voice 100
 destination dpg 200
dial-peer voice 200
 destination dpg 100

Each inbound dial peer names an outbound dial-peer group: a call that arrives from Webex Calling on dial peer 100 always leaves through dial peer 200 toward the ITSP, and a call from the ITSP on dial peer 200 always leaves through dial peer 100 toward Webex. The PSTN dial peer is matched by the carrier's address in the Via header (incoming uri via 200). For a CUCM connection, Cisco's design adds a third pair of dial peers and dial-peer groups in the same style.

Certificate-based differences

• CUBE gets a host certificate from a supported CA (crypto pki enroll, crypto pki authenticate, crypto pki import) and uses it as the default signaling trustpoint under sip-ua.
• The tenant points to a Webex SRV address, for example sip-server dns:us25.sipconnect.bcld.webex.com, and sets localhost dns:cube1.lgw.com so that SIP headers carry the gateway's FQDN, which must match its certificate.
• A voice class sip-options-keepalive profile monitors the Webex SBCs, and the URI class matches the trunk FQDN or SRV (for example, pattern cube1.lgw.com) instead of a dtg.
• The firewall must allow Webex Calling to reach the gateway on the port configured for the trunk.

---

5. Firewall and Media Ports

The gateway's media port range is configurable with the rtp-port command. When ICE optimization succeeds for a call within the organization, the cloud media relay drops out of the path and media flows directly between the endpoints.

---

6. Call Flow: Webex Calling User to the PSTN

1. A Webex Calling user in the Dallas location dials +12125550199.
2. Webex Calling checks the user's outgoing permissions (Section 9.4), sees that the location uses premises-based PSTN, and selects the location's trunk or route group.
3. Webex Calling sends the INVITE to CUBE over the connection that CUBE registered, with the trunk's dtg in the Request-URI.
4. CUBE matches inbound dial peer 100 through the URI class, and dial-peer group 200 selects outbound dial peer 200 toward the ITSP (or a POTS dial peer for a PRI).
5. The carrier's 180 and 200 OK responses return through CUBE, and two-way media flows: SRTP toward Webex Calling, RTP or the carrier's choice toward the PSTN.

---

7. Troubleshooting a Local Gateway