Cisco Cisco Expressway Maintenance Manual
This function manages restrictions at the domain / chat node alias level. Individual user-based privacy is
controlled by each client / end-user.
controlled by each client / end-user.
The allow list and deny list modes are mutually exclusive. A domain/alias cannot be allowed and denied at
the same time.
the same time.
When federation is first enabled, Privacy mode is set to Allow list by default. In effect this puts the system
in a 'lockdown' mode — you will not be allowed to connect with any federated domains or chat node aliases
until you either add them to the allow list, configure static routes, or change the Privacy mode setting.
in a 'lockdown' mode — you will not be allowed to connect with any federated domains or chat node aliases
until you either add them to the allow list, configure static routes, or change the Privacy mode setting.
1. On Expressway-E, go to
Configuration > Unified Communications
.
2. Set Privacy mode as appropriate:
l
Off: No restrictions are applied.
l
Allow list: Federation is allowed only with the domains and chat node aliases specified in the allow list.
l
Deny list: Federation is allowed with any domain or chat node alias except for those specified in the
deny list.
deny list.
3. Click Save.
4. To manage the domains and chat node aliases in the allow or deny lists, click either Federation allow
list or Federation deny list as appropriate.
In the resulting page you can add, modify or delete the items in the allow/deny list. Wildcards or regexes
are not allowed in the names; it must be an exact match.
In the resulting page you can add, modify or delete the items in the allow/deny list. Wildcards or regexes
are not allowed in the names; it must be an exact match.
All domains and chat node aliases that are configured as static routes are included automatically in the allow
list.
list.
DNS SRV records for XMPP federation
If federating parties are not using static routes to access federated XMPP services, suitable DNS SRV
records must be published.
records must be published.
_xmpp-server records
You must publish an _xmpp-server DNS SRV record in DNS for your local domain so that remote
enterprises can access your federated XMPP services. For example:
enterprises can access your federated XMPP services. For example:
Domain
Service
Protocol
Priority
Weight
Port
Target host
example.com
xmpp-server
tcp
0
0
5269
vcse.example.com
Similarly, to allow federating parties to discover a particular XMPP federated domain (if they are not using
static routes), the federated enterprise must publish an _xmpp-server DNS SRV record in its public DNS
server. For example:
static routes), the federated enterprise must publish an _xmpp-server DNS SRV record in its public DNS
server. For example:
Domain
Service
Protocol
Priority
Weight
Port
Target host
federated.com
xmpp-server
tcp
0
0
5269
xmppserver.federated.com
All enterprises must publish the service on port 5269. The published FQDNs must also be resolvable in DNS
to an IP address.
to an IP address.
Cisco Expressway Administrator Guide (X8.2)
Page 71 of 378
Unified Communications
External XMPP federation