...
An additional advantage of using TLS for remote gateways is that users of the remote system can be mapped to a sipXecs user, and may then use resources which require permissions (e.g. ITSP gateways, etc). To enable this mapping, add a TLS Peer under the Users menu, using as the TLS Peer Name the identity which the remote system presents in the SubjAltName field of its certificate (usually the SIP Domain or FQDN of the remote system). You can then specify permissions to be applied when any users from that system dial. 
If no matching TLS Peer is configured, then a warning message will be logged in sipxbridge.log, containing the list of identities which were in the certificate: "No matching TLS Peer found for <list of identities in the certificate>.
Note that for this to work, the certificate sent by the remote system must implement draft-ietf-sip-domain-certs-04.txt , which recommends that the SIP domain identity be conveyed as a SubjAltName extension of type uniformResourceIdentitier .
Troubleshooting TLS connections
If the remote system's CA certificate is not installed, then a TLS connection will not be established and calls will be rejected with reason xxx.
If the remote certificate identity (from the SubjAltName field) does not match the remote system's address, then a TLS connection will not be established and calls will be rejected with reason 5xx "Certificate identity does not match requested domain". In this case, an alarm will be raised stating "The configuration requires the identity '<expected remote identity>', but the remote certificate contains only the following identities: <list of identities in the certificate>". sipXecs requires that remote systems support draft-ietf-sip-domain-certs-04.txt, which recommends that the SIP domain identity be conveyed as a SubjAltName extension of type uniformResourceIdentitier, and that that identity must match the domain to which the request is being sent.