Apr 142013
 

 

Apr 132013
 

Frequently I find a need to do something with Windows, and VBScript is a flexible and fairly powerful language capable of doing all sorts of useful things. Granted there is JavaScript and PowerShell; and I should learn JavaScript more since there are several utilities that Avaya (formerly Nortel) has developed to collect data on systems and being able to write my own utilities to make myself more effective is a desirable skill.

I was writing a not-work-related utility this weekend and used several web sources to refresh my memory on how various VBScript functions, statements and operators worked. Here’s a list of some of those links:

Dim myArray(10)

myArray(0) = “Nothing to see, move along.”

Erase myArray

Mid( myString, 3, len(myString)-2 )

Replace( myString, “Find me”, “Replace me”, 1, -1)

Dim re

Set re = New RegExp

re.Pattern = “^We hold these truths.*”

re.IgnoreCase = true

re.Test( myString )

Dim re

Set re = New RegExp

re.Pattern = “These are the droids we”

re.IgnoreCase = true

myJediMindTrick = re.Replace(“These are the droids we are looking for”, “These are not the droids you”)

Dim myString

Dim myObject

Dim myInteger

myString = Empty

myObject = Nothing

myInteger = Null

‘ Although you could also use Empty on the integer variable.

UBound(myArray) returns the total number array elements (regardless of element values). isEmpty(myArray) returns false on arrays even if all array elements are empty.

Quick tip:

Const vbQuote = “”””

myString = vbQuote & “Quickly” & vbQuote & ” add quotation marks to any string.”

If Not booleanDroidsWeAreLookingFor Then

Call continueLooking

End if

On Error Resume Next

On Error Goto 0

I looked this up and discovered this really doesn’t do anything that I really want to happen. It would be nice if VBScript had a little bit more powerful error throwing/catching… sadly, it does not.

Mar 092013
 

Here are all of the trace messages I’ve been able to identify.

 

Acquire

Acquire_Resp

Answer

AnswerIndication

Answer_Resp

Application_Polling

CallAbandonedQueue

CallOffered

CallRouted

Release

ReleaseAcquire

ReleaseAcquire_Resp

ReleaseIndication

Release_Resp

RouteCall

RouteCall_Resp

RouteRequest

SF_StartRecord

SF_StartRecord_Resp

SF_StopRecord

SF_StopRecord_Resp

SFN_ActivityCode

SFN_Login

SFN_Logout

SFN_MakeSetBusy

SFN_MakeSetInService

SFN_NotReady

SFN_Ready

SFN_Return

SFN_StartRecord

SFN_StopRecord

SFN_WalkAway

StatusChange

 

  • An MLSM Trace message always begins:
    ff 0a 00
  • The fourth word is always the word-length of the message (including the three word header)
  • The fifth word is always the Associated ID
  • From there it gets a lot more complicated– I wish there was some documentation I could lay hands on.
    • 96 06 + 4 words is the Call ID which matches AML trace or Call By Call stats
    • 0e 00 02 + 10 words is the Calling Line ID associated with a call. Each digit in a CLID is broken out into a separate word ranging from 30 for 0 to 39 for 9. As an example, the number 877-555-1212 would be represented by 38 37 37 35 35 35 31 32 31 32.

I do have a breakdown of several CallRouted, RouteCall, RouteCall_Resp and RouteRequest messages, but unfortunately the pattern is consistant and I know for certain there are other call types (sources, numbering plans, etc.) that could be represented in the traces… I just don’t have examples of them.

It was kind of fun to write a parse utility to grab all of the clear-text headers and then write another procedure that would use those headers to collate all of the responses so that I could look for patterns. It’s similar to DCH traces. Given enough time I’m sure I can find out a number of obvious patterns within the hex codes… (like 96 06 and 0e 00 02… I’ve already noticed that oe 00 02 represents only one type of calling line ID. There are other hex patterns that might also include CLID information. Origination Type, Origination Address, Destination Type, Destination Address… there might be a few more.

Mar 072013
 

I’ve been dealing with a number of complicated cases recently for work requiring that I review mass quantity of multi-meg trace files (text files outputting raw log information). The reason for this is because the customer that I’m working with is using a CTI application (Chrysalis Cloudburst) to control call routing and perform screen-pop functionality at the agent’s desktop when the call arrives. As part of that process, Cloudburst accepts the call from the IVR application and then performs a CTI route via MLSM (Meridian Link Services Manager).

--------    Output from mlsm.exe        Tue Feb 19 09:13:43.781 2013   (13:43.781)
ITR Route
                  03 1f 00 00 00 00 1e 34 a5 8b 00 00    header (12 bytes)       
                                             95 01 05    Subtype (Route)      
                                    96 04 00 00 2f c1    Call Id       
                                          4b 02 66 26    CDN (6626)      
                                          31 02 66 a3    Terminating DN (6603)      
                                             67 01 00    Conditional (unconditional)      
=======================================================================================
--------    Input                       Tue Feb 19 09:13:43.781 2013   (13:43.796)
ITS Route
                  03 22 00 00 00 00 1e 35 a5 8b 00 00    header (12 bytes)       
                                             95 01 05    Subtype (Route)      
                                    96 04 00 00 2f c1    Call Id       
                                          4b 02 66 26    CDN (6626)      
                                          31 02 66 a3    Terminating DN (6603)      
                                             67 01 00    Conditional (unconditional)      
                                             aa 01 00    Status (Successful request)      
=======================================================================================

When you’re looking for twenty or thirty trace entries across three to twelve trace files, representing hundreds (or potentially thousands) of trace entries… it gets to be both time consuming and tedious. I decided to code a parse utility to make my life easier. Part that process is converting the decimal call ID (in the example above, Decimal 12225) to a hex call ID and properly formatting that hex value (hex 2fc1) so that it can be searched for in the trace files.

While I have no intention of releasing the full parse utility to the public (if you really want a copy, contact me via LinkedIn, or comment on this blog and we’ll discuss it), I thought it might be helpful for those “do it yourselfers” who might want a hint at how to overcome one of the challenges I had to overcome to get this utility functional.

I’m using VBScript running as a cscript:

'**
'* function convertCIDtoCallID integerCallID
'* returns stringFormattedHexCallID
'*
'* Converts a decimal call ID to a hex string call ID with spaces between each byte (for use in searching AML logs)
'*

function convertCIDtoCallID( iCID )
 ' convert decimal Call ID to hex, then convert to lowercase
 hCID = lcase(hex(iCID))
 sRetVal = ""

 ' if the number of characters in the hex Call ID is odd, then we need a leading 0 inserted
 if (len(hCID)%2)=1 then
  hCID = "0" & hCID
 end if

 ' for each character from 1 to the length of the hCID string
 for i=1 to len(hCID)
  ' group hex values in groups of two characters
  if ((i mod 2) = 1) and (i>2) then
   ' insert a space between hex value groups
   sRetVal = sRetVal & " "
  end if
  ' append the current character to the return value
  sRetVal = sRetVal & mid(hCID,i,1)
 next

 ' return the formatted hex call ID string
 convertCIDtoCallID = sRetVal

end function

What this does is convert a decimal value to hex (12225 to 2fc1) and then formats it the way it might appear in an AML trace (2f c1). It also automatically adjusts for scenarios where the hex value is 3 hex digits (hex fc1 = dec 4033) to something that can be searched for (0f c1) instead of mishandling (fc 1, which would not be found in the traces.)

This should save me hours in reviewing log files.

Jul 172008
 

Resetting a Nortel IP phone just became a lot easier.  Nortel has announced in their Unistim 3.0 documentation the ability to reset a Nortel IP phone to factory default settings.  The following code is required to reset to factory default:

  • **RENEW[mac]##

Where [mac] is replaced by your MAC address.  Example: If your MAC address is 00:11:22:33:44:55, then your reset code would be:

  • **73639001122334455##

For more information on what the factory default settings are, refer to the Unistim 3.0 Revision 1 product bulletin located on Nortel’s Partner Information Center webpage.

NOTE
You must have valid Nortel Partner credentials to access this bulletin.