SIP Path Replacement and Tromboning

In a TDM world we all take path replacement for granted. If I transfer a call to an IVR application and then back out I do not expect to be using up 2 T1 or E1 channels for the remainder of the call.

Similarly in the SIP world if I transfer a call across a SIP trunk and then back again I would not expect to use a SIP channel for each call leg.

However, this is exactly the behaviour we are currently experiencing on this project. The call is initially delivered to the Avaya switch and is then transferred to the Genesys side over a SIP trunk and we use GVP and/or Stream Manager to apply treatments. When an advisor becomes available we transfer the call to that target on the Avaya switch. If the advisor then needs to transfer the call via a queue we again go back over SIP to the Genesys side, apply treatments again and select a new (Avaya) target.

In the Avaya CMS trunk utilisation report below for the same call the problem is obvious:

Image

To demonstrate the problem and to eliminate GVP and Stream Manager from the call flow we did the following:

  • A Sipek Softphone SIP endpoint which supports call transfer for free unlike X-Lite! (http://sipekphone.googlepages.com/) was connected to Genesys SIP Server (2102) and configured to be dial-able from the Avaya switch e.g. uniform dial plan and AAS as (42102)
  • The Genesys SIP extension is dialled from an Avaya station (6717) and we see 1 channel in use in the Avaya CMS trunk group report (100)
  • The call is then transferred from the Genesys SIP endpoint to another Avaya station (6715). At this point there are 2 SIP trunks in use e.g. no path replacement occurs.
  • The call is transferred from the 2nd Avaya station (6715) back to the Genesys SIP extension (42102). At this point there are 4 SIP trunks in use!

In the SIP world REFER and REINVITE methods are used for call transfer. I’ve checked the initial INVITE from the Avaya switch and the REFER method is allowed as shown below:

Image

At this moment in time we do not have a solution and I’ll keep you informed. I’m sure the answer is something to do with REFER …

Share

Component Upgrades

As I mentioned in my earlier posts, this week we upgraded to SIP server 8. Component upgrades are common especially during the development phases of any project. Over the years I have developed my own technique for this which may seem lazy but which I believe fits better with a well enforced change and release management process (not that I’m into ITIL too heavily!) because it makes the backout procedure simple and therefore reduces the risk.

The technique I use is as follows:

  • Review the release notes and asses the impact of any new application options. Add these options to the existing application template
  • In the development environment install the new application from setup.exe
  • Test, test, test! If all is OK promote the new application to other environments by a) updating application options b) making a backup of the current .EXE and c) overwriting the current .EXE with the new version

The advantage of this approach is that I can quickly revert back to the old .EXE if something goes wrong. As a side effect the application version reported in CME is often wrong as it refers to the old application template. Of course this can be changed directly in the configuration database to keep things in step. But as I said I am a bit lazy!

For this reason I always check the versions of the actual executables and do not rely on CME application templates to tell me which version of a component I am running. This is why the configuration audit tool I have developed retrieves version information directly from the executable.

Share

Configuration Snapshots

We all know that one little application option can make all the difference between a working solution and something that appears to be completely broken. Similarly, we have also all encountered the situation where something was working and then suddenly stops working – often because a standby component has kicked in and we forgot to change an application option on both the primary and the backup components (a sackable offence in my opinion 🙂 )

This situation is often compounded when there are multiple Genesys environments to manage as is the case on my current project were we have the luxury of development, non production and production environments.

Whilst framework 8 has introduced some useful configuration auditing it still leaves a lot to be desired and does not address the issue of multiple environments.

Therefore this week I wrote a Configuration Audit application in C# .NET using the platform SDK to read CME objects as well some other configuration elements such as the actual .EXE version deployed for each application, SQL server database and instance information, Virtual Hold (VHT) options (of which there are many) and GVP / EMPS configuration via LDAP.

The output from each environment is a single text file which I can then compare across environments using WinMerge (http://winmerge.org/). Equally within the same environment the tool can also be used to output the options for high availability pairs and compare them.

The screenshots below show the differences between two configuration snapshots taken in the same environment before and after the weekend.

Image

Image

I have now configured a scheduled task in all environments to take a daily configuration snapshot which should make change and release management much easier in the future.

Share

Virtual Hold Resilience

As I mentioned in an earlier post we are using Virtual Hold (http://www.virtualhold.com/) as part of the solution for this client.

OOTB Virtual Hold does not have any true resilience. Therefore we have deployed VHT on two seperate servers and have configured two Genesys SCI solutions and associated alarm conditions to failover between the primary and backup servers.

VHT uses a number of flat files to store scheduled callbacks and associated attached data and these folders have been configured as network shares (replicated Windows DFS shares actually).

VHT has two associated IVR (GVP) applications – one to schedule the callback and one for callback delivery. As part of the standard callflow the Customer is requested to record their name and this is then replayed on callback delivery as a message “This is a scheduled callback for xxxxx”.

We had a problem today trying to configure the location of the capture folder where the recorded name is stored.

Investigation revealed the following:

  • The ASP page ‘CALLBACK_GetName.asp’ returns the filename and path to save the captured name to
  • After capture a post back occurs to ‘CALLBACK_CAPTURENAME.asp’ which returned the following error:

2009-10-02 09:28:03 W3SVC1 10.176.201.109 POST /PILOT_IVR/3.5/ASP/CALLBACK_CAPTURENAME.asp
SESSIONID={8A8F9676-9A70-4693-9727-8AED5613AD3B}|203|800a0007|Out_of_memory:_’FS.GetParentFolderName’ 80 – 10.176.201.103 Mozilla/4.0+(compatible;+Telera+_ND_C+7.6.410.02) 500 0 0

  • ‘CALLBACK_CAPTURENAME.asp’ includes ‘recordingsupport.inc’ which contains the VBScript in question:-

Sub CreateFolderPath(ByVal Path)
Dim FS
Dim Parent
Set FS = CreateObject(“Scripting.FileSystemObject”)
Parent = FS.GetParentFolderName(Path)
If Not FS.FolderExists(Parent) Then
CreateFolderPath Parent
FS.CreateFolder Parent
End If
End Sub

The problem was caused by a bug in the ASP pages generated by the Genesys Voice Studio application which prevents Universal Naming Convention (UNC) names being used in the capture path. The fix is as follows:

Edit the file “CALLBACK_GetName.asp” and change

strVoxFileName = Replace(strVoxFileName, “\”, “\\\\“)

to

strVoxFileName = Replace(strVoxFileName, “\”, “\\”)

Share

Numbering Plan Change

For this client we use trunk access codes to get calls from the Avaya switch to the Genesys (SIP) switch and back again. In our development and non-production environment we have been using ‘1111’ to get calls to the Genesys switch and ‘1112’ to get calls from Genesys back to the Avaya switch. Therefore, on the Genesys SIP side, all our DNs have been prefixed with ‘1111’ and ‘1112’ has been added as part of the access code on each external routing point (ERP) back to the Avaya switch.

This week we discovered an Avaya numbering plan problem / conflict in the production environment which meant that we needed to change our DN numbering plan on the Genesys SIP side.

Since we have quite a few DN’s configured for routing points, external routing points and voice treatment ports, each with associated Annex data and access codes, I did not really want to risk deleting the DN’s and re-creating them again. Also, since we are using Genesys Info Mart in this architecture the impact of changing the DBIDs of these objects was unknown.

Therefore I decided to make the changes at the configuration database level. e.g. stop config server, make the database changes and re-start config server. Everything worked fine and I saved myself hours of re-configuration whilst at the same time minimising the risk of forgetting to add some annex data. Here is the SQL:

Image

You may also notice from the SQL that we are using Virtual Hold (http://www.virtualhold.com/) in the solution and therefore each IVR (voice Treatment Port) needed to be re-configured. I’ll probably post a bit more about my experiences with VHT in the future 🙂

The final part of the numbering plan change involved EMPS provisioning which was done manually. The necessary changes being as follows:

  • Add re-numbered IVR ports to “DID Groups -> Default”
  • From “Resellers -> GVPOwner -> Admin -> Provision” add new Prov DIDs for each GVP / IVR application
  • From “IPCS -> PopGateway -> SIP” change the starting number for PortIds on each IPCS server

Phew!

Share

Avaya SIP Interoperability (Revisited)

Following on from my earlier post (http://genesysguru.com/blog/blog/2009/09/26/avaya-sip-interoperability/) this week we upgraded to Genesys SIP Server 8.0.100.17 to test interoperability with CM 5.2 (CM 02.0.947.3 to be precise):

Image

Whilst initial testing was very promising we found a problem when we tried to transfer a call back into a queue using Genesys Stream Manager on the Genesys SIP side. Basically, the second treatment would fail.

With the help of Genesys support and a Wireshark SIP trace the solution was found.

Image

Set the option ‘sip-early-dialog-mode=false’ on the outbound (back to Avaya Trunk DN). On the inbound (from Avaya) Trunk DN leave ‘sip-early-dialog-mode=true’:

Image

Looks like we now have a stable solution to move into production.

Share