GVP 7.6 with secure voice using Secure RTP (SRTP)

In a previous post here (http://genesysguru.com/blog/blog/2011/09/14/implementing-secure-voice-using-secure-rtp-srtp/) I mentioned that Genesys GVP 7.6 components do not support voice encryption using Secure RTP (SRTP) and also proposed a solution architecture using Session Border Controllers (SBC) with Back to back User Agent (B2BUA) functionality deployed in front of Genesys Voice Platform (GVP) 7.6 instances to act as a bridge between secure voice traffic (SRTP) and insecure voice traffic (RTP).

Well, I am pleased to confirm that technically this works and at no material cost other than blood, sweat and tears!

I do not have time to describe the full solution here but please feel free to contact me (http://genesysguru.com/blog/contact-me/) if you want some more information.

Before I get into the detail, if you take away one think from this post it is when playing with TLS on Genesys components make sure that your certificates are correct as this took me hours to sort out.

OK, let’s get started.

For my proof of concept I used FreeSWITCH (http://www.freeswitch.org/) as a Session Border Controller. This is an EXCELLENT open-source product that can be used for all sorts of things including resolution of SIP interoperability issues.

The main steps were:

  1. Install FreeSWITCH (5 minutes!)
  2. Configure FreeSWITCH
  3. Generation and installation of TLSv1 self-signed (untrusted) certificates (painful)
  4. Enabling of TLS on Genesys SIP Server
  5. Reconfiguration of GVP / IPCS
  6. Reconfiguration of Voice Treatment Port DNs in CME
  7. Reconfiguration of Avaya (optional)
  8. Testing

Install FreeSWITCH

Just run “freeswitch.msi”!

For testing purposes, I also installed the FreeSWITCH Client which is a softphone which supports secure voice. I also installed CounterPath Bria 3 which is a commercial softphone (http://www.counterpath.com/bria.html).

Configure FreeSWITCH

I needed to modify the Access Control Lists (ACL) to add Local IP network segments into the allowed domains list – you may not need to do this.

I edited the file “C:\Program Files\FreeSWITCH\conf\vars.xml” to enable TLS and set the TLS version to TLSv1 rather than SSLv2.3:


Initially I created SIP profiles which are used to configure gateways (SIP endpoints) for each GVP/IPCS instances. However, after some testing I decided that this was not required as everything could be achieved in the dialplan and out of service (OOS) checks on gateways did not provide any real benefit (see later).

The meat of the configuration is in the FreeSWITCH dialplan.

The XML dialplan is the default dialplan used by FreeSWITCH. Dialplans are used to route calls to endpoints. These endpoints can be traditional extensions, voicemail, IVR or other applications. Dialplans are separated into contexts that allow separate dialplans to be created for different call types.

Within a context are extensions which contain condition rules and associated actions which are performed when the condition rules match. Essentially, extensions can be used in the same way as Avaya Vectored Directory Numbers (VDN). Each rule is processed in order until an action (or anti-action) is reached. There can be multiple conditions and actions (anti-actions) in a single extension.

Condition rules are specified using Perl regular expressions which can be used to test channel variables.

Actions can include applications such as the “bridge” application which is used to bridge two endpoints physically or “set” and “export” which are used to manipulate channel variables.

To enable SRTP the dialplan must check to see if the variable ${sip_has_crypto} contains the data indicating that the calling device supports SRTP. Then, in order to enable SRTP to be used, the dialplan must set the variable sip_secure_media=true. It is as easy as that!

For the proof of concept I wanted to bridge calls for GVP ports in the range 80110xx to the relevant GVP/IPCS server. To do this I created a new file in the “C:\Program Files\FreeSWITCH\conf\dialplan\public” folder which contained the following dialplan:


I used OpenSSL to create my own Certificate Authority (CA) and then each user certificate.

The important thing to note is that the name given for Common Name (CN) in the user certificate must be the same as the name used as the registrar (domain) name on SIP endpoints.

For Genesys components, each PEM encoded certificate and key needs to be exported to a single PKCS (Public-Key Cryptography Standards) #12 (PKCS#12) file. To install the certificates on Windows 2003, the Certificates Snap In needs to be added to MMC.

To install the certificates required for FreeSWITCH, copy the root CA certificate file “cafile.pem” to “C:\Program Files\FreeSWITCH\conf\ssl” and the relevant user certificate for the FreeSWITCH server (host) to “C:\Program Files\FreeSWITCH\conf\ssl” and then rename it as “agent.pem

During a test call check the SIP server logs for the following error:

12:52:44.714 Std 08102 Secure connection error, ‘socket 716, InitializeSecurityContext failed, syserror 80090322, The target principal name is incorrect.

The “Target principal name is incorrect” error means that the peer certificate does not contain the name that the server the TLS connection is to. Alternatively, the “Certificate root not trusted” error means that the peer certificate was issued by a remote CA that is not trusted by the local machine.

As I just said, the important thing to note is that the name given for Common Name (CN) in the user certificate must be the same as the name used as the registrar (domain) name on SIP endpoints.

Enabling of TLS on Genesys SIP Server

For TLS, there is a dependency to install Genesys SIP server 8.0.400.xx. I tested with SIP Server 8.0.400.39.
The following options need to be configured on the SIP server application object in CME and then SIP server restarted:

  • sip-port-tls = 5061
  • sip-tls-cert = (see below)
  • sip-tls-mutual = false
  • sip-tls-crl = [no value]
  • sip-tls-target-name-check= no
  • sip-tls-cipher-list= [no value]


I wasted a couple of hours playing with the “sip-tls-cipher-list” option but just leave it blank as it seems to make no difference anyway!

The value for the “sip-tls-cert” option is taken from the thumbprint in the user certificate for the SIP server (host) and not the root CA certificate. The thumbprint can be obtained by double clicking on the “.p12” file and then selecting the details tab.


If you get this wrong you will see the error “cannot find certificate” in SIP server logs.

If this error has occurred it means that either the certificate has not been installed correctly or SYSTEM does not have the correct permissions on folder “C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys“:


If everything is configured correctly, then log file should look as follows:


Reconfiguration of GVP / IPCS

Each GVP / IPCS instance needs to be reconfigured to so that it does not register GVP ports with SIP server since this overrides the “contact” details specified on each GVP voice treatment port DN. This is configured in EMPS and when requires a watchdog restart:


Please note the following important impact of this change:

Normally, in a back of switch configuration with GVP 7.6, each IPCS is configured to register its ports with SIP Server and the option “use-register-for-service-state” is configured on each GVP voice treatment port DN in CME. This enables active out of service (OOS) detection each IPCS instance. When an IPCS instance fails the registration times out (after up to 30 seconds) the status of all associated ports goes unavailable in Stat Server.

Hence, the strategy which routed to the IVR place group will not route calls to OOS GVP ports. Given the registration timeout period there is however still no absolute guarantee that calls are not routed to an OOS IPCS instance.

This configuration is required because GVP 7.6 does not support OOS detection using ping of SIP OPTIONS messages which is the normal mechanism for OOS detection in SIP environments. OOS detection using SIP OPTIONS is only supported on Genesys DNs of type “VoIP Service” and “Trunk”. It is not supported on DNs of type “Voice Treatment Port”.

The effect of the change to “use-register-for-service-state=false” is that GVP ports always remain available in Stat Server even when GVP / IPCS is down. In SIP environments, the standard approach to OOS detection is:

  1. Active OOS detection
  2. Try to route calls and handle any failures. However this introduces some delay e.g. 3 seconds based on the FreeSWITCH dialplan parameter “call_timeout=3”
  3. A combination of both (1) and (2)

By default, FreeSWITCH responds “200 OK” to any SIP OPTIONS request it receives if there is a SIP profile configured and running on the associated port e.g. 5060. In essence, this response just means that FreeSWITCH is available and not that the downstream route end to end e.g. through to GVP / IPCS is available. Therefore, configuration of a Trunk DN in CME for each FreeSWITCH server, enabling OOS and checking the trunk status in the routing strategy would not provide any value.

Within FreeSWITCH SIP profiles (gateway) configuration files there is a parameter “ping” which specifies the interval to send a SIP OPTIONS message to a gateway e.g. GVP / IPCS in order to determine its OOS status e.g. gateway up or down. If a gateway is down any attempt to route calls to it in the dialplan would result immediately in a status of “NETWORK_OUT_OF_ORDER” e.g. no timeout / latency.

FreeSWITCH provides failover on the bridge application by allowing multiple destinations to be specified and dialled sequentially using the “|” separator. Hence, using the ping parameter on the gateway allows FreeSWITCH to determine a gateway has failed which allows the bridge to go to the secondary immediately rather than waiting for a timeout.

However, as previously mentioned, GVP 7.6 does not support OOS detection using SIP OPTIONS. Hence, this option cannot currently be used.

Hence, the only possible solution is the following hybrid approach to out of service (OOS) detection:

Firstly, the IVR routing strategy is modified to check the status of a Third Party application object created in CME for both the FreeSWITCH application and also the Watchdog executable for IPCS. This gives a very good real-time view of the availability of both a GVP/IPCS instance and its associated FreeSWITCH / SBC server. If either is not available the call is not routed any ports hosted on this GVP / IPCS instance.

Secondly, the FreeSWITCH dialplan is configured with the call-timeout set to 3 seconds to catch any errors which occur after the initial check e.g. the call is routed to a GVP port. This will result in an error being returned to SIP server if the end to end route is not available. The IVR routing strategy is modified such that in this circumstance it routes the call to another GVP / IPCS instance. The net effect of this is a 3 second delay in being routed to a GVP port.

Reconfiguration of Voice Treatment Port DNs in CME

As mentioned above, the option “use-register-for-service-state” must be set to false. Also, the contact details much be changed to point at the FreeSWITCH server on port 5061 rather than GVP / IPCS itself on port 5060 and also using “transport=tls”.


Reconfiguration of Avaya (optional)

In my proof of concept environment we have Avaya Communication Manager (ACM) sitting in front of Genesys and using SIP trunking via Avaya SIP Enablement Services (SES) in between. Since I wanted to test full end to end voice encryption I also needed to configure TLS and secure Voice on the Avaya side.

Note: Officially TN2302 IP Media Processors do not support SRTP (they actually do!) so if you are using SRTP use the TN2602. Use the command “display circuit-packs” to confirm.

The main steps are:

  • The option “Media Encryption Over IP” must be set to “y” in System Parameters -> Customer Options.
  • On the associated IP Codec Sets, the “Media Encryption” options and order must be set.The encrypted network region needs to have an unencrypted (none) codec at the end of the media encryption list to enable non secure (RTP) sessions to be negotiated with Genesys Stream Manager which does not support SRTP (this can be changed later when Media Server is used to replace Stream Manager as this component does support SRTP). During the re-INVITE to a GVP port, a new session will be negotiated using SRTP from Avaya to GVP via the SBC / FreeSWITCH.


  • On the route patterns for the SIP signalling groups, the option “Secure SIP” must be set to “y”.
  • On the SIP signalling groups, the “Transport Method” must be set to “tls” and the listening ports set to “5061”.
  • Add the IP address of the FreeSWITCH host into the trusted host list in SES and also into the encrypted network region in ACM.
  • Modify the SES maps to specify “transport=tls” outbound to Genesys SIP server.


We are done!

Firstly, I did quite a lot of testing without TLS enabled using a Wireshark or FreeSWITCH sip trace (sofia global siptrace on) to see if the “a=crypto” line was present in the SIP messages.

I also ran the FreeSWITCH CLI command “show channels” and looked for the line “srtp:AES_CM_128_HMAC_SHA1_32” in the trace.


I did some testing with Bria 3 on an account with TLS and secure voice configured. Notice the lock symbol next to call established. This shows that the voice traffic is secured:


I made an end to end test call without TLS specified as the transport on GVP ports. A Wireshark RTP trace clearly shows RTP traffic between Avaya (.138), FreeSWITCH SBC (.117) and GVP/IPCS (.111) including RTP DTMF Event payloads from Avaya:


With TLS then re-enabled, a Wireshark RTP trace no longer shows RTP traffic to or from Avaya (.138) including RTP DTMF Event payloads from Avaya. All unencrypted RTP traffic is between FreeSWITCH SBC (.117) and GVP/IPCS (.111) within the same PCI Island:


Job done and thanks for reading!