Outbound from the Cisco Webex cloud

  • The destination of a call must use standards-based SIP Secure (SIPS) URI dialing. Other call protocols or methods, such as insecure SIP over TCP or UDP, H.323, IP dialing, ISDN, Microsoft Lync, or Microsoft Skype for Business, are unsupported.

  • The destination address must be a URI with both a user and host portion as defined in RFC 3261.

  • The host portion of a destination URI must be a (sub)domain with a _sips._tcp. DNS SRV record, or either a Fully Qualified Domain Name or IPv4 address of a Session Border Controller (SBC) which has a SIPS server listening on the protocol's default port (TCP 5061).

  • If the destination is a DNS SRV target or host FQDN, there must be a corresponding DNS A record pointing to IPv4 addresses of any SBCs.

  • The destination SBC must present a server certificate that is not expired.

  • If the destination SBC is a Cisco TelePresence VCS or Cisco Expressway, the minimum supported software version is X8.5.3.

Recommended best practices for the destination SBC are:

  • Present a TLS certificate that contains the SBC's FQDN in either the CN or SAN DNS records.

  • Present a complete TLS certificate chain including any signing intermediate CA certificates, and the signing root CA certificate.

  • Present a TLS certificate signed by a trusted public root Certificate Authority (CA). For the list of root CAs trusted by Cisco Webex, see Supported Certificate Authorities for Cisco Webex.

  • Have a DNS PTR record configured for the SBC's FQDN.

Additional notes to keep in mind:

  • Cisco Webex Teams users or devices that use Cisco Webex Hybrid Calling must have their B2B calling requirements defined by the on-premises equipment configuration, such as Cisco Unified Communications Manager (Unified CM) and Cisco Expressway.

  • You can test your SBC's DNS SRV records and connectivity using the Cisco TAC Collaboration Solutions Analyzer.

Inbound to the Cisco Webex cloud

  • The originating Session Border Controller (SBC) of a call must use standards-based SIP Secure (SIPS) URI dialing. Other call protocols or methods, such as insecure SIP over TCP or UDP, H.323, IP dialing, ISDN, Microsoft Lync, or Microsoft Skype for Business, are not supported.

  • The originating SBC must be configured to use a DNS server capable of performing DNS A record and SRV record lookups.

  • The originating SBC must be capable of using the _sips._tcp DNS SRV record corresponding to the subdomain in the dialed URI's host portion to locate the FQDN of the Cisco Webex SIPS server, and resolving the A record for the FQDN to determine the IPv4 address to connect to. The originating SBC must be able to connect to the Cisco Webex SIPS server on the IP address determined from the DNS lookups, and be able to negotiate SIP over TLSv1.1 or TLSv1.2.

  • If the originating SBC supplies an FQDN in its Contact header, there must be an accompanying DNS A record which resolves this FQDN to an IPv4 address.

  • The originating SBC must use a SIP INVITE message to initiate a call rather than a SIP OPTIONS message.


    If you use a Cisco TelePresence Video Communication Server (VCS) or Expressway to interwork the call from H.323, you must create a DNS zone for Cisco Webex with the Zone profile set to Custom and Automatically respond to SIP searches set to On. The VCS or Expressway's Search Rules must likewise be configured to route B2B calls for Cisco Webex to this DNS zone.

  • If the originating SBC is a Cisco TelePresence VCS or Cisco Expressway, the minimum supported software version is X8.5.3.

Recommended best practices for the originating SBC are:

  • Present a TLS certificate signed for both client and server usage.

  • Present a TLS certificate that contains the SBC's FQDN in either the CN or SAN DNS records.

  • Present a complete TLS certificate chain including any signing intermediate CA certificates, and the signing root CA certificate.

  • Present a TLS certificate signed by a trusted public root Certificate Authority (CA). For the list of root CAs trusted by Cisco Webex, see Supported Certificate Authorities for Cisco Webex.

  • Have a DNS PTR record configured for the SBC's IPv4 address which points to the SBC's FQDN.

  • Establish a mutual TLS connection to the Cisco Collaboration Cloud on TCP port 5062.

    • If you are using a Cisco VCS-Expressway or Cisco Expressway-Edge as the SBC, this can be done using a custom DNS zone for Cisco Webex which has the TLS verify mode and Modify DNS request options set to On, and the TLS verify subject name and Domain to search for fields set to callservice.ciscospark.com. For more information, see the Deployment Guide for Hybrid Call Service , section "Configure the Expressway-E for Hybrid Call Service Connect".

    • Note that if implementing this recommendation, the above recommendations regarding the SBC's TLS certificates will be mandatory or else the calls will fail.

Additional notes to keep in mind:

  • The above requirements also apply for connecting to Cisco Webex Teams meetings that do not use a Cisco Webex site.

  • The above requirements apply for calls to a user or device's Cisco Webex SIP URI.

Required Firewall and Network Ports

Please note that these network ports are subject to change without notice, depending on demand capacity and other cloud requirements. These ports also only refer to the connections between the Cisco Webex platform and destination or originating SBC, and do not reflect the connection between the Cisco Webex platform and Cisco Webex Teams apps or devices.

  • Signaling for calls to Cisco Webex: SIPS via TLS over TCP to cloud ports 5061–5062

  • Signaling for calls from Cisco Webex: SIPS via TLS from ephemeral TCP cloud ports 1024–61000

  • Media (audio, video, screen share, and so on) to and from Cisco Webex for inbound or outbound calls: RTP, RTCP, BFCP, UDT over UDP to and from cloud ports 33434–33598. Ports on the SBC depend on the SBC configuration/ By default, a Cisco VCS-E or Expressway-E uses UDP 36000-59999.

Media Flow Information

The media flow for Webex Teams calls depends on what is configured in your deployment. For more information about the media flows and how they're influenced when various components are involved, see the following documentation: