Using TLS and sipXtapi

Introduction
Secure signalling in sipXtapi can be achieved by using the TLS (SSL) features.  TLS has
been implemented using the Netscape Security Services api (NSS).  More on NSS is
available at http://www.mozilla.org/projects/security/pki/nss/overview.html

Runtime requirements
	NSS binaries
	sipXtapi requires that the runtime DLLs of NSS (version 3.9) and 
	NSPR (version 4.4.1) be present in the working
	directory, as siblings of the sipXtapi.dll.
	Below is the list of required DLLs:
		nspr4.dll
		nss3.dll
		nssckbi.dll
		plc4.dll
		plds4.dll
		sipXtapid.dll
		smime3.dll
		softokn3.dll
		ssl3.dll
	NSS Security Database
		Another requirement of the TLS feature of sipXtapi is that a valid
		Certificate Database be created.
		An NSS Certificate Database can be created with the certutil tool.  
		In addition to creating a Certificate Database, a certificate should
		also be created for use as an TLS server certificate - 
		this certificate should also specify a "subject alternate name".
		Documentation for the certutil tool can be found on:
		http://www.mozilla.org/projects/security/pki/nss/tools/certutil.html

Enabling TLS
	TLS can be enabled by passing some parameters to the sipxInitialize function:
	TLS Port	- Specifying a port value other than SIPX_PORT_DISABLE will
			cause sipXtapi to attempt to load the NSS runtime binaries and 
			will attempt to create a TLS server on that port.
	TLSCertificateNickname - Nickname of the certificate to use as an SSL server.
	TLSCertificatePassword - Password for the certificate database.
	DbLocation 	- Path to the certificate database.
			
Identities and URIs
	Remote parties can be called with TLS signalling in two ways:
	Transport Tag - 	Append the tag "transport=tls" to the URI.  For example,
				<sip:115@pingtel.com:5061;transport=tls>
				The port value should be included, unless the DNS SRV lookup 
				returns the correct port value for TLS.
	SIPS Scheme - 	Use the "sips:" scheme instead of "sip:".  For example,
				<sips:115@pingtel.com:5061>

Event Callbacks
	When placing or receiving a call over TLS, it is the application's responsibility
	to either accept or reject the remote party's certificate.  The application does
	this by returning either true (to accept), or false (to reject) from the event
	callback, when it receives a SECURITY_TLS event with the cause code of
	SECURITY_CAUSE_TLS_SERVER_CERTIFICATE.  In the info structure for this event,
	is the certificate pointer (NSS function calls are available for verifying the
	CA chain), the call handle, and the server's subject alternate name.  This
	information should be sufficient in order to determine whether to accept or
	to reject the certificate.