Aurus Blog

This blog is to share our expertise in Cisco UCM, UCCX/UCCE and Cisco Meeting Server

  • Archive

    «   May 2022   »
    M T W T F S S
                1
    2 3 4 5 6 7 8
    9 10 11 12 13 14 15
    16 17 18 19 20 21 22
    23 24 25 26 27 28 29
    30 31          

Cisco Expressway 12.5.5. Remote Videoconferencing without VPN (Part 3)

TURN

TURN stands for Traversal Using Relays around NAT. Basically, it’s a device that is publically accessible from the Internet and can send and receive multimedia. To function properly, it must be accessible for external devices on the Internet as well as for internal devices (such as CMS), so audio and video traffic can come in and out the organization. In such case, the TURN server acts as an anchor point for the media that is trusted by the firewall.

By the way, the CMS server can be deployed as an edge device and function as a TURN server, but since the Expressway-E has TURN server capabilities as well, it seems reasonable to configure it in Expressway instead of creating extra CMS servers or increasing the load on the existing CMS server. Regardless of which device is used as a TURN server to anchor media, the TURN server must be configured in the CMS database so that the Call Bridges know where to send media and, since the TURN server is on the public internet, the web client can know where to send its traffic. An Expressway-E, acting as a TURN server, will bridge the traffic received on its internal and external interfaces together so that users can establish two-way communication.

For any device to use a TURN server, authentication is required. You should configure a set of authentication credentials on the Expressway-E to use for TURN.

Create a “Traversal…” user account.

Configure the Expressway-E TURN server.

TURN in CMS

If there’s no cluster, you can simply specify the TURN CMA and TURN CMS addresses in CMS web interface.

Port 5222 or port 5223

It’s better to use the secure port 5223 in ServerAddress field. However, in this case we are using port 5222 because we have a wildcard certificate in CMS, and it can only have a domain and “*.domain” in CN and SAN. So, the actual address of CMS web portal doesn’t coincide with CN and SAN in the certificate, which means we can’t use 5223, only 5222.

TURN CMS (serverAddress) — The IP address that CMS should expect to get traffic from when clients connect to a conference.

TURN CMA (clientAddress) — The address that clients (both internal and external ones) should send traffic to in order to take part in a conference.

TURN CMA (clientAddress) and TURN CMS (serverAddress) can be one and the same address if Expressway-E has a public IP address and is not located behind any NAT. If Expressway-E is behind a NAT device, then TURN CMA is the public IP address that Expressway is being translated into. TURN CMS (serverAddress) is a local IP address in the corporate network. For the same reason port 3478 should be open from Cisco Meeting Server towards Expressway-E.

If Expressway-E is located behind a NAT, then you should configure NAT Reflection on your firewall. Basically, it makes it possible for internal clients and/or devices to be rerouted to Cisco Meeting Server address as they connect to a conference using TURN CMA (clientAddress).

NAT Reflection is also needed for MRA, because if Expressway-C initiates connection with Expressway-E by “knocking” on the private IP address of Expressway-E, then Expressway-C will require an RMS license for calls from/to a jabber device that is outside the corporate network (i.e. calls will be treated as B2B). To avoid this, you should create an A record in your internal DNS pointing at the public address of Expressway-E, and NAT Reflection will reroute the traffic towards Expressway-E to the private IP address.

Working with NAT

For a cluster, use Postman to configure TURN on any of CMS cluster nodes, and these settings will be applied to other nodes automatically.

Create TURN servers and fill in the following parameter values:

  • serverAddress
  • clientAddress
  • username
  • password
  • type

We have already discussed the first and second parameters. Third and fourth are the login and password for the user account we have created in Expressway-E. The last parameter is the type of TURN server (in our case that’s Expressway, but it could be CMS as well).

For a cluster, two or more TURN servers should be created (the number equals the number of Expressway servers in a cluster).

In status, we can see if TURN is available for CMS and so on, see below.

Specify CMS

In order for Expressway-C to see CMS cluster, you should configure your internal DNS server. In the external domain zone (if you have a Dual Domain scenario), create a join directory with a _tls subdirectory. Inside the _tls subdirectory, create three DNS SRV records named _cms-web with corresponding priorities, pointing at DNS A records: cms01.internal-domain.com, cms02.internal-domain.com, cms03.internal-domain.com.

Enter “join.[external]-example.com”, so Expressway will see all servers in a CMS cluster:

Now turn on MRA (Mobile and Remote Access).

Turn On MRA

On Expressway-C:

On Expressway-E:

It’s recommended to change the default Expressway-E port from 443 (for example, to 445). If Expressway-E is clustered, perform this action for each of them. If you leave the port number unmodified, your external users will connect to Expressway-E Web Admin instead of CMS.

Note that your firewalls must have the following ports open:

Follow your URL: join.example.com to check if the web portal is available from outside.

There are different ways to configure call routing:

  • Route calls to Cisco UCM;
  • Route calls to Cisco Expressway-C (preferable).

The difference is what acts as the central call routing node. You can also perform a flexible configuration using CMS and Expressway priorities.

In our case, it will be the second option. See the picture below (it was taken from the Deployment guide, so please disregard everything that’s outside the firewall).

Routing on CMS

Incoming calls

Outbound calls

You can set CUCM as a SIP proxy (as a first option), but it requires the CUCM itself being properly configured (trunks, SIP Rout Patterns, Route Lists, etc).

Business to Business calls

Business to Business (B2B) calls are the major feature of Expressway. B2B enables performing video calls, calls from/to organizations, external video services and clients on Internet, while safely bypassing corporate firewalls.

B2B calls are based on a possibility of call routing through Expressway. This can also be achieved through domains, CUCM and most of the other SIP call management objects, but Expressway also has the concept of a DNS zone. You don’t have to identify the remote destination of a call explicitly. Instead, Expressway DNS finds the call destination outside the organization network. Our DNS zone is already configured.

Create a search rule for incoming calls on Expressway-E

In our company, you can only perform an incoming call to a special conference with the following SIP-URI: meeting@example.com

We’ll create a regular expression: meeting@example\.com\.*

You can read more about these parameters in the documentation or use the tips in Expressway.

To put it simply, an incoming SIP call from DefaultZone, that has meeting@example.com in its destination address, will be routed to UC Traversal zone.

Create a search rule for outgoing calls on Expressway-E

We’ll create a regular expression: "(?!.*@%localdomains%.*$).*"

An incoming SIP call (coming from Expressway-C side) from UC Traversal zone that has a non-local domain(s) after @ in its destination address will be routed to the DNS zone for a destination lookup (matching the value after @ with its IP address on the Internet) and a successful call.

Transforms

If you have Dual Domain, then the external domain must be transformed into internal. The following regular expressions can be used: "(.*)external.com((:|;).*)?" and "1\@internal.com"

Create a search rule on Expressway-C

Regular expressions:

  • .*@example.com
  • .*@example.com
  • .*@example.com
  • .*@(cucm-01\.|cucm-02\.)?example\.com\.*
  • .*@(cucm-01\.|cucm-02\.)?example\.com\.*
  • (?!.*@(cucm-01\.|cucm-02\.)?example\.com\.*

Transforms

You should also add transformations for correct call routing.

  • Strip :5060 from Outgoing URIs
  • Transform destination aliases to URI format
  • Replace IP within Domain dialing from CUCM-Publisher
  • Replace IP within Domain dialing from CUCM-Subscriber
  • Let’s make test calls. Call a conference with Cisco RoomKit Mini from inside the organization, from outside (using a B2B call with Cisco RomKit Plus), and connect through the web as well.

    Connect to the conference through web:

    Call from outside:

    Call from inside:

    The conference has been gathered.

    For the record, 1900@external.com and 999@internal.com are registered on their CUCMs.

    What was it like for Expressway and CMS:

    Incoming call on Expressway-E:

    Details of the call passing through Expressway-E:

    Incoming call on Expressway-C:

    Details of the call passing through Expressway-C:

    Incoming call on CMS:

    Sources:

    Read also:

    Cisco Expressway 12.5.5. Remote Videoconferencing without VPN (Part 2)

    Certificates

    Expressway servers need certificates to communicate with each other. That’s why root and intermediate certificates of the CAs that issued certificates for your servers must be listed as trusted.

    Proceed to Maintenance menu > Security > Trust CA certificate. Upload those root and intermediate certificates.

    In our case, the certificate for Expressway-C was issued by a local CA, which is equivalent to self-signed, and Expressway-E has a certificate issued by Let’s Encrypt (a free certificate that must be renewed every 3 months). Expressway has an auto renewal feature that will be described below.

    Concerning the free Let’s Encrypt certificates:

    • Open intermediate certificate and root certificate links.
    • To be accepted by Expressway, a .p7b chain must be converted into a root certificate.
      In Windows 10:
      a. Right click on this file and select Open with > Crypto Shell Extensions
      b. Right click on DST Root CA X3, select All Tasks, Export and Save.
      In Linux, convert p7b to pem using this command:
      openssl pkcs7 -inform der -in dstrootcax3.p7c -print_certs -out dstrootcax3.pem
    • Copy the internals of an intermediate certificate into notepad and save it.
    • Upload both certificates to Expressway-E, Trust CA section.

    Root and intermediate certificates of a local CA are marked in red.

    Root and intermediate certificates of Let’s Encrypt CA are marked in blue.

    • Generate a certificate signing request for Expressway-C.

    No subject alternative names are needed for Expressway-C.

    In Unified CM phone security profile names, you should enter the Phone Security Profiles created in Unified CM, but this setting is only needed for TLS interactions between Expressway-C and CUCM. In our scenario, it is not needed.

    • Send the request to the private CA, get a certificate and upload it to Expressway-C.
    • Generate a certificate signing request for Expressway-E in a similar way. Add a SAN: join.example.com, example.com or collab-edge.example.com, if there’s a DNS A record for example.com pointing at your corporate website IP address. You also have to create a DNS A record for collab-edge.example.com in the external DNS server, or the request will be rejected.

    Without example.com or collab-edge.example.com, Cisco Jabber clients will give you ‘unreliable certificate’ warnings.

    • Click Deploy Pending Cert.
    • If everything has been done correctly, it should look like this.

    Note: in version 12.5.6, there’s a BUG concerning this matter. Versions 12.5.7 and 12.5.8 have been retracted due to security problems, so please upgrade to 12.5.9.

    Zones

    A zone is an abstract set of anything (domains, IP addresses, devices, services) with a certain set of rules. You can use zones to configure bandwidth, call routing and authentication, and apply these settings to everything within a zone. When you create Dial plans, you select zones the call should be passed to/from (instead of selecting domains).

    There are several types of zones.

    • Neighbor — a zone for connectivity with CMS, CUCM or other Expressway-C.
    • Localzone — a zone including devices registered to Expressways.
    • ENUM — for E.164 requests.
    • DNS — for DNS requests.
    • Webex — for scenarios with calls being passed from a corporate network to the Internet and then to a cloud. Similarly, calls from a Webex meeting are routed through the Internet and passed to the local routing system.
    • Traversal (Client, Server) — for firewall traversal during call routing between Expressway-C and Expressway-E.
    • UC Traversal — for Jabber with all its features to be reachable from the Internet.
    • Default — whatever doesn’t belong to any other zone, falls here and works according to Default zone rules (if you have no rules, everything will be rejected).

    So, let’s proceed to Expressway-C and create Neighbor zones for CUCM and Cisco Meeting Server.

    Zones for CUCM

    There should be a separate zone for each of CUCM servers in publisher and subscriber cluster(s). If you create a single zone and specify all servers in address fields, then only one in N calls will pass, with N standing for the number of servers in the CUCM cluster. Same for CMS.

    In our case, there are only two servers.

    The first zone:

    The second zone:

    You should also create a SIP Trunk Security Profile and a Trunk from CUCM to Expressway.

    SIP Trunk Security Profile

    Please note that you should set the incoming port to 5065, or it won’t work.

    Trunk

    Now you should set the port number to 5060. If you use 5065, it will work, but the trunk’s status won’t change to Full Services and will always stay Unknown. You should also specify the correct CSS (depending on your configuration), and set the previously created SIP Trunk Security Profile and Standard SIP Profile for Cisco VCS as SIP Profiles.

    Zones for CMS

    If it’s just a single server and not a cluster, you can leave the Zone Profile Default.

    If you have a cluster, you should fill the address fields with FQDNs of all clustered servers and set Meeting Server load balancing to ON.

    UC Traversal Zone (Expressway-C)

    In our case, H.323 protocols are not used, so we create a UC Traversal Zone, not just Traversal.

    On Expressway-C, configure a client connection in UC Traversal zone. In relation to traversal tunnel between Expressway-C and Expressway-E, Expressway-C is a client. It establishes a tunnel from local network to Expressway-E (which is in DMZ), so that signaling can be passed through the corporate firewall in both ways. That’s why we should enter the login/password that will be created on Expressway-E (where we configure the server part of UC Traversal zone).

    Now, on Expressway-C, it should look like this:

    Neighbor zones (and rules for that zones) CEtcp… will be created automatically if you explicitly set a CUCM in Expressway-C (Configuration > Unified Communications > Unified CM servers).

    In CUCM 12.5, an Expressway will be created automatically as well.

    UC Traversal Zone (Expressway-E)

    Usually, Expressway-E is located in the DMZ and has an interface that is accessible from the Internet (sometimes this interface address is behind NAT). Most firewall policies don’t allow incoming connections from the DMZ to the local network. However, most firewall policies allow outgoing connections from the local network to the DMZ and the Internet. Expressway-E is configured as a traversal server, being able to accept connections from firewall traversal clients (such as Expressway-C) which are inside the local network. These connections are used for two-way communication between Expressway-E and Expressway-C.

    On Expressway-E, you should create a user for the traversal connection. Let’s call it uctraversal.

    Configure the UC Traversal Zone.

    DNS Zone

    First of all, DNS Zone is for searching DNS SRV records in order to find the destination for a called domain. For SIP, it looks for _sips._tcp. domain and/or _sip.tcp. domain, depending on encryption and security settings. You can configure Expressway to perform standard A record requests, too, in order to find a call's destination if a search for SRV records fails. Such calls make it possible for Expressway to route calls to destinations that aren’t defined explicitly. You can simply register the corresponding DNS SRV records in a public DNS server, and then get calls from external clients automatically and/or call them if they have performed the same action. That’s called open federation or Business-to-Business (B2B) calls.

    In the next part of this article, we’ll talk about TURN configuration and Business to Business (B2B) calls.

    Read also:

    Cisco Expressway 12.5.5. Remote Videoconferencing without VPN (Part 1)

    It’s time to make corporate communication services available remotely with no additional efforts like using Cisco Anyconnect and/or creating VPN tunnels.

    In this article, we’ll tell you how to configure Cisco Expressway server to make videoconferencing work from outside your office as well.

    Cisco Expressway provides a secure firewall for voice and video sharing, and supports many features, such as B2B calls, mobile and remote access (MRA), and also TURN server capabilities (Traversal Using Relay NAT). So, this can be called a Single Edge solution which is a preferable borderline solution for unified communications and Cisco Meeting Server.

    Licensing

    Cisco Expressway servers can be deployed as Core (Expressway-C) and Edge (Expressway-E). If they are being deployed from scratch, they are not Expressways at first, they are simply VCS servers. You must install the required licenses to make them Expressway servers.

    Each server (no matter Edge or Core) requires a LIC-SW-EXP-K9 license (to put it simple, a Release key).

    Core servers require the following licenses:

    • LIC-EXP-GW
    • LIC-EXP-SERIES

    Edge servers require the following licenses:

    • LIC-EXP-GW
    • LIC-EXP-SERIES
    • LIC-EXP-E
    • LIC-EXP-TURN

    Optionally, you can add the following licenses:

    • LIC-EXP-MSFT-PMP — Microsoft Interoperability Option (for Expressway-C), it is required for interactions with Skype for Business;
    • LIC-EXP-RMS-PMP — Rich Media Session licenses (for both Expressway-C and Expressway-Е);
    • LIC-EXP-DSK — Expressway Desktop Endpoint license (for Expressway-C), to register personal endpoints to Expressway;
    • LIC-EXP-ROOM — Expressway ROOM license (to register video codecs to Expressway);
    • LIC-TP-ROOM — to register codecs to CUCM (optionally includes LIC-EXP-ROOM);
    • LIC-EXP-AN — Advanced Networking option, an additional network interface (for both Expressway-C and Expressway-Е)

    Rich Media Session license consumption depends on the connection type:

    • Connections to/from Expressway Registered Endpoints;
    • Connections to/from Expressway Non-Registered Endpoints;
    • Connections to/from through Traversal Zone;
    • Connections to/from Cisco Cloud Service;
    • Connections to/from UCM, Conductor, CMS or Expressway through Neighbor Zone.

    In my case, the virtual machines have been already deployed and network interfaces have been configured.

    Looking forward, there are different scenarios of Expressway-C and Expressway-E bundle deployment.

    In terms of domains, there are two options:

    1. Single domain (if you have a single domain, e.g. example.com, to be used both inside and outside your network).

    2. Dual domain (internal domain is example.local, external domain is example.com).

    In terms of topology, it’s recommended to use two network interfaces, one for each separate DMZ. However, we’ll consider two options:

    1. DMZ with a single local network interface for Expressway-E.

    You can use a public IP address given by your internet provider. No need to configure NAT Reflection at your firewall to make Cisco Meeting Server work outside your network.

    2. DMZ with two local network interfaces for Expressway-E.

    To use this feature, you should have Advanced Networking option active in Option keys section.

    Besides, in both cases you have to specify whether this IP address will be visible from outside the NAT.

    DNS

    You should create the following external/internal DNS records (depending on whether you are deploying a clustered or non-clustered, Single or Dual Domain server):

    Single Domain

    DNSTYPERecordPurpose
    ExternalAexp-e. external-example.comExpressway-E internet address. You can use any other name.
    ExternalAjoin. external-example.comPoints to Expressway-E address. Required for connecting to CMS conference via WebRTC.
    ExternalSRV_collab-edge._tls. external-example.comPoints to Expressway-E address. Required for telephony, messenger and voice mail services to be discovered by Jabber client app. Port 8443.
    ExternalSRV_sip._tcp. external-example.comPoints to Expressway-E address. Required for incoming calls. Port 5060.
    ExternalSRV_sip._udp. external-example.comPoints to Expressway-E address. Required for incoming calls. Port 5060.
    ExternalSRV_sips._tcp. external-example.comPoints to Expressway-E address. Required for encrypted incoming calls. Port 5061.
    InternalSRV_cisco-uds._tcp. internal-example.comPoints to Cisco UCM’s A record. Required for telephony services to be discovered by Jabber client app. Port 8443.
    InternalSRV_cuplogin._tcp. internal-example.comPoints to Cisco UP’s A record. Required for messenger services to be discovered by Jabber client app. Port 8443.
    InternalSRV_xmpp-client._tcp. external-example.comPoints to Cisco Meeting Server’s A record. Required for clients to find XMPP server.
    InternalSRV_xmpp-server._tcp. external-example.comPoints to Cisco Meeting Server’s A record. Required for CallBridges to find XMPP server.

    Dual Domain

    DNSTYPERecordPurpose
    ExternalAexp-e. external-example.comExpressway-E internet address. You can use any other name.
    ExternalAjoin. external-example.comPoints to Expressway-E address. Required for connecting to CMS conference via WebRTC.
    ExternalSRV_collab-edge._tls. external-example.comPoints to Expressway-E address. Required for telephony, messenger and voice mail services to be discovered by Jabber client app. Port 8443.
    ExternalSRV_sip._tcp. external-example.comPoints to Expressway-E address. Required for incoming calls. Port 5060.
    ExternalSRV_sip._udp. external-example.comPoints to Expressway-E address. Required for incoming calls. Port 5060.
    ExternalSRV_sips._tcp. external-example.comPoints to Expressway-E address. Required for encrypted incoming calls. Port 5061.
    InternalSRV_cisco-uds._tcp. internal-example.comPoints to Cisco UCM’s A record. Required for telephony services to be discovered by Jabber client app. Port 8443.
    InternalSRV_cisco-uds._tcp. external-example.comPoints to Cisco UCM’s A record. Required for telephony services to be discovered by Jabber client app. Port 8443.
    InternalSRV_cuplogin._tcp. internal-example.comPoints to Cisco UP’s A record. Required for messenger services to be discovered by Jabber client app. Port 8443.
    InternalSRV_cuplogin._tcp. external-example.comPoints to Cisco UP’s A record. Required for messenger services to be discovered by Jabber client app. Port 8443.
    InternalSRV_xmpp-client._tcp. external-example.comPoints to Cisco Meeting Server’s A record. Required for clients to find XMPP server.
    InternalSRV_xmpp-server._tcp. external-example.comPoints to Cisco Meeting Server’s A record. Required for CallBridges to find XMPP server.

    Please note that if you have a Dual Domain server, you should create a zone with an external domain in your internal DNS, and then create the red-marked records in it. So, the users will be able to use the same login for their Cisco Jabber apps, whether they are logging in from inside or outside the corporate network (with an external domain, login names usually coincide with corporate email addresses).

    You should also create domains and select the services to be supported for this domains.

    Services

    • SIP registrations and provisioning on Expressway — indicates if Expressway is trusted for this SIP domain. Expressway acts as a SIP registrar and presence server for this domain, and also accepts registration requests from all SIP clients trying to register with an alias that includes this domain.
    • SIP registrations and provisioning on Unified CM — indicates if Expressway acts as a gateway for CUCM to provide safe pass through a firewall and support endpoint registration to CUCM.
    • IM and Presence Service — indicates if Expressway acts as a gateway for IMP and supports messenger and presence services.
    • XMPP federation — for a local domain that requires XMPP federation services (a domain that participates in federation with any other domains).

    Please note that if you need static routes for federated external domains, they should be configured on Expressway-E.

    If you are using Dual Domain scenario, you should enter both domain names in Expressway-C and Expressway-E configuration sections (or all domain names, if there are more than two of them).

    In the next part of this article, we’ll go on with Expressway configuration (specifically, we’ll talk about certificates and zones).

    Read also: