Have you ever written a cool tool, put it up on GitHub and then totally forgotten to tell everyone about it? Well, I wrote a call Sonus/Ribbon PowerShell log parser and forgot to tell everyone. And it’s super embarrassing!
Why?
I got so sick and tired of firing up Ribbons on “LX” tool every single time a call went “awry” when customers escalated an issue. Only to find someone else had re-installed LX on their profile causing the installation to break on mine. (a LONG standing bug in LX)
For people that only support a pair of SBC’s maybe you can just run LX on your desktop or personal jump box. But for consultants like me, we have to get the files off the SBC and then download the files from the customer’s environment which usually has its own problems. Needless to say, even with LX on your personal machine you still need to read all the ROUTE entries by hand anyway.
So I wrote this script to give everyone a simple way to see what rules are being parsed for calls to ease troubleshooting a bit.
The script will look for a WebUi.log in the current directory and then search for any invites in that file. Displaying a list of calls, the translations applied, what routing table and what rules the call passed through to reach its destination signalling group.
You can even search an entire folder using the -ParseFolder flag!
Download
You can download a signed version of the code over on my GitHub as well as more documentation in the Readme.md on GitHub and listed below.
Terminology
Just a quick note to alleviate any confusion if you haven’t done lots of TransTable work on a Sonus/Ribbon SBC.
A Translation Table Entry is a single RegEx rule that matches a single attribute, IE a Called Number or a Calling Number. But not both
A Translation Table contains multiple Translation Table Entries and can have multiple entries match, if all the relevant properties match (IE, both called and calling) then the table is deemed successful
A Route Table contains multiple Translation Tables, each mapping to a destination signalling group.
The route table is determined by the signalling group the call arrives on and the destination signalling group is determined by what translation table is successful first.
Script Parameters
‘InputFile’ : The file to process, will default to Webui.log if not specified or not parsing the whole folder
‘ParseFolder’ : Will process every log file in the current directory, useful for audits before turning off signalling groups and avoiding scream tests
‘OutboundSignallingGroups’ : Will only show calls that match the outbound signalling group ID specified. To get the Signalling Group ID, in your SBC navigate to Settings > Signalling Groups and check the Primary Key for the group you are interested in.
Neat Tricks
Looking to find a call that ends routes to a certain signalling group? Use the OutboundSignallingGroup parameter!
'PS> Search-UxCallLog.ps1' -ParseFolder -OutboundSignallingGroups 2 | ft
Looking for a simple way to filter all the logs in a folder for a call? Just pipe it to PowerShell’s Grid View cmdlet.
PS> Search-UxCallLog.ps1 -ParseFolder | ogv
Script Output
Search-UxCallLog will presently output any found call details on the PowerShell Pipeline. Each call is a PSCustomObject object, with the following properties.
‘CallID’ : The SBC’s internal call ID for the found invite, can be found in the X-Sonus-Diagnostics headers in the Invite
‘CallTime’ : The time the SBC processed the initial invite
‘InviteLineNumber’ : The line number in the log that the SBC logged “Handling initial invite.”
‘OriginalCallingNumber’ : The calling party’s number as logged by the SBC
‘OriginalCalledNumber’ : The called party’s number as logged by the SBC
‘TranslatedCallingNumber’ : The called party’s number used in the first outbound Invite for the Call ID above
‘TranslatedCalledNumber’ : The calling party’s number used in the first outbound Invite for the Call ID above
‘RouteTable’ : The route table used by the SBC for the inbound Invite
‘TransTableMatches’ : The Translation Table that caused the SBC to send a new outbound invite
‘TransTableFailures’ : The Translation Tables that were tested before the successful table was found
‘TransTableEntrySkips’ : The Translation Table Entries that were skipped because they are disabled.
‘FinalTranslationRule’ : The Translation Table Entry that caused the Translation Table to Succeed
‘OutboundSignallingGroups’ : This is currently a plain text string of all the signalling groups listed in the destination route. Will be updated to an array in a later release
‘CauseCodeReRoute’ : Returns what if any cause code rules were matched and what table the match was on. Otherwise returns “No”
‘ReRouteMatch’ : Returns the Translation Table match of the re-routed call.