Requirements for Endpoints

Webex Calling Edge

To perform a SIP registration or call, complete these steps:

  • Discover the host address of a SIP endpoint for active Edge nodes.

  • Complete any preconditions related to user and device configuration.

  • Ensure that the endpoint has public network connectivity to start service discovery.

  • Complete the preconditions of bootstrapping the endpoint with a region or datacenter-specific provisioning configuration. This configuration helps to obtain the relevant domain name suffix for service discovery.

IPv4 versus IPv6

Devices can operate in a single-version or dual-stack mode. It’s configuration that determines the changes to the preferred protocol and these changes aren’t part of service discovery.

  • Single-stack mode—enables only one IP protocol (for example, IPv4) and ignores the other protocol addresses.

  • Dual-stack mode—selects a preferred IP version through configuration.

The client considers the priority for all preferred addresses to be lower (that is, preferred) than all addresses of the IP. If IPv4 is preferred, all IPv4 addresses are attempted before attempting an IPv6 address. If all addresses fail, the cycle starts again with the lowest priority preferred protocol address.

A mobile client registering on receipt of a push notification can decide to optimize the mode based on previous registrations.

Resolution of host address from the DNS SRV address

In the endpoint configuration file obtained from provisioning, the domain indicator specifies the domain name to discover the access edge service. An example of the domain name is:

wxc.edge.bcld.webex.com

From the example, the endpoint performing a DNS SRV lookup for this domain may yield a response similar to the following:


# nslookup -type=srv _sips._tcp. wxc.edge.bcld.webex.com
_sips._tcp.wxc.edge.bcld.webex.com SRV 5 100 5061 sip-edge1.us-dc1.bcld.webex.com.
_sips._tcp.wxc.edge.bcld.webex.com SRV 10 105 5061 sip-edge2.us-dc1. bcld.webex.com.

In this case, the SRV record points to 3 A records.


sip-edge1.us-dc1.bcld.webex.com
sip-edge2.us-dc1.bcld.webex.com

In the example, all hosts are advertised to contact port 5061 with differing weight and priority.

Consider these requirements for endpoints.

  • An endpoint must use _sips._tcp (service & protocol combination) as the prefix to perform a DNS SRV lookup for obtaining host address for initiating TLS-based communication.

  • An endpoint must do a DNS SRV lookup for the conditions explained in the Resolution of host address from the DNS SRV address section.

  • An endpoint must honor host, port, weight & priority as advertised for each of the host address. Also, it must create an affinity of host to port when creating a socket connection during SIP registration.

  • Specific to usage of the DNS SRV record, the selection criteria of hosts based on priority & weight is explained in RFC 2782.

Requirements for SIP and Media

Requirement

Description

Trust certificate required for public key encryption

Refer to article, to know about Webex certificates’ signing authority and Root CA required on devices

TLS version supported for secure SIP

TLS 1.2

TLS ciphers supported for secure SIP

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

TLS_DHE_DSS_WITH_AES_128_GCM_SHA256

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

TLS_DHE_RSA_WITH_AES_128_CBC_SHA256

TLS_DHE_DSS_WITH_AES_128_CBC_SHA256

TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256

TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256

TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256

TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256

SRTP Keys supported for secure media

AES_CM_128_HMAC_SHA1_80

Requirements for Secure SIP with mTLS (mutual TLS)

The requirements are explained in detail here.

A Signed certificate is required for a successful authorization and authentication of calls from the trunk. The certificate must meet the following requirements:

  • The certificate must be signed by a CA mentioned in  What Root Certificate Authorities are Supported for Calls to Cisco Webex Audio and Video Platforms?

  • Upload the trust bundle mentioned in  What Root Certificate Authorities are Supported for Calls to Cisco Webex Audio and Video Platforms? on to the CUBE.

  • The certificate should be valid always:

    • Signed certificates must always have a valid expiry.

    • Root or intermediate certificates must have a valid expiry and must not be revoked.

    • Certificates must be signed for client and server usage.

    • Certificates must contain the Fully Qualified Domain Name (FQDN) as a common name or subject alternate name in the certificate with the FQDN chosen in the Control Hub. For example:

      • A trunk configured from your organization’s Control Hub with london.lgw.cisco.com:5061 as the FQDN must contain london.lgw.cisco.com in the certificate CN or SAN.

      • A trunk configured from your organization’s Control Hub with london.lgw.cisco.com was the SRV must contain london.lgw.cisco.com in the certificate CN or SAN. The records that the SRV address resolves to (CNAME/A Record/ IP Address) are optional in SAN.

    • You can share certificates with more than one Local Gateway, however, ensure that the FQDN requirements are satisfied.

Out of Scope

This article doesn’t include the following information related to network security:

  • F5 requirements for CA and Ciphers

  • An HTTP-based API to download firewall rules for Webex.

  • API for a trust bundle

  • Firewall requirement & ALG disablement