Polycom VVX Hold Issue with Sonus SBC1000/2000 Calls

I had an issue recently when using the VVX Music on Hold feature in conjunction with a Sonus SBC1000/2000. The problem was that the VVX phones could not put a trunk call on hold (in this case they were running 5.4.5 software) . The symptom of this issue was the following message being displayed on the VVX screen (“Hold Failed. Moving back to call”):

It should be noted here that the VVX in question had the new Music on Hold feature configured and MoH was working to internal Skype for Business clients and other phones. This was only happening on trunk calls on the Sonus gateway.  This would happen for both Sonus based file hold music (ie. Sonus gateway based hold) or when the Sonus was not being used to supply the hold music (ie. hold passed through from the VVX to the outside party).

Logging on the system showed that the RE-INVITE message being sent by the mediation server to initiate hold was getting rejected by the Sonus SBC. The INVITE message that was being sent looked like this:

RE-INVITE message sent by Mediation Server to Sonus Gateway:

INVITE sip:+61395821300@10.20.1.150:5066;transport=TCP SIP/2.0

FROM: <sip:+61395824500;ext=4500@myskypelab.com;user=phone>;epid=BB69FBB4BE;tag=45afae0d8

TO: <sip:+61395821300@SBC1000GW.myskypelab.com;user=phone>;tag=7b66d712-5fc

CSEQ: 83 INVITE

CALL-ID: a9adec59-5f57-4a9c-ac31-78836eb506a3

MAX-FORWARDS: 70

VIA: SIP/2.0/TCP 10.20.2.104:49796;branch=z9hG4bKbafabbee

CONTACT: <sip:2013ENTFE004.myskypelab.com:5068;transport=Tcp;maddr=10.20.2.104;ms-opaque=7b0cff35b7212cae>

CONTENT-LENGTH: 246

SUPPORTED: timer

SUPPORTED: 100rel

USER-AGENT: RTCC/5.0.0.0 MediationServer

CONTENT-TYPE: application/sdp

Session-Expires: 1800

Min-SE: 90

v=0o=- 1477456907 1477456908 IN IP4 10.22.0.23s=sessionc=IN IP4 10.22.0.23t=0 0a=sendonlym=audio 60034 RTP/AVP 0 101c=IN IP4 10.22.0.23a=rtcp:60035a=sendonlya=rtpmap:0 PCMU/8000a=rtpmap:101 telephone-event/8000a=ptime:80

You will notice in the above invite that the Mediation server is requesting a Payload Size of 80ms (“ptime:80”). The Sonus gateway doesn’t like this though, and rejects the call with a 488 message:

Call setup rejected:

SIP/2.0 488 Not Acceptable Here

FROM: <sip:+61395824500;ext=4500@myskypelab.com;user=phone>;epid=BB69FBB4BE;tag=45afae0d8

TO: <sip:+61395821300@SBC1000GW.myskypelab.com;user=phone>;tag=7b66d712-5fc

CSEQ: 83 INVITE

CALL-ID: a9adec59-5f57-4a9c-ac31-78836eb506a3

VIA: SIP/2.0/TCP 10.20.2.104:49796;branch=z9hG4bKbafabbee

CONTENT-LENGTH: 0

WARNING: 304 "Media type not available"

SERVER: SONUS SBC1000 5.0.4v415 Sonus SBC

When the 488 message gets fed back to the VVX, it displays the “Hold Failed. Moving back to call” message and everyone is very sad :(

Why is this happening?

The Sonus gateway supports a maximum payload sizes of 60ms. This can be seen in INVITE messages sent out of the Sonus like the one below:

v=0

o=SBC 79 1001 IN IP4 10.20.1.150

s=VoipCall

c=IN IP4 10.20.1.150

t=0 0

m=audio 20112 RTP/AVP 0 8 101 13

c=IN IP4 10.20.1.150

a=rtpmap:0 PCMU/8000/1

a=rtpmap:8 PCMA/8000/1

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

a=rtpmap:13 CN/8000

a=ptime:20

a=maxptime:60

a=sendrecv

As you can see in the SDP message above, the Sonus says that it will only handle a maximum payload size of 60ms. There is also a reference to this in the SBC1k/2k manuals, which state that “If the SBC receives a larger than configured payload size from the peer offer in the re-invite, the SBC rejects with a 488 'Not Acceptable Here' response. The call rolls back to the previous negotiated offer answer.” – Reference: https://support.sonus.net/display/UXDOC60/Creating+and+Modifying+Voice+Codec+Profiles

The Fix!

So the fix turns out to be a VVX phone setting. When initiating hold the VVX the phone doesn’t follow the regular payload size settings for the codec being used (which by default for PCMA/U is 20ms). Instead it has a setting called feature.moh.payload which defaults to 80ms. Fortunately for us, this setting can be changed within the configuration file (it’s not available in the web interface!). The setting for Music on Hold are shown below:

Setting	Default Value	Required Value
feature.moh.enabled	0	1
feature.moh.filename	NULL	Set this to the hold music file name. The file will be served off the config server. The default file is “Polycom-hold.wav”
feature.moh.payload	80	20 or 40 or 60
res.quotas.tone	600	600 – 1024

Note: The default moh file size is 600KB which works fine for the default hold music provided by Polycom. However, if you want to change this to your own file then you can expand the size up to 1024KB.

Polycom has made the payload setting 80ms by default to reduce the processor usage on the phone when it plays the hold file. So selecting 60ms may be the best option from a processor load perspective (which will work with the Sonus max payload size of 60). This way the hold music will work correctly, without putting too much load on the VVX's CPU.

Here is an example of how this might look in a config file:

<feature feature.moh.enabled="1" feature.moh.filename="Polycom-hold.wav" feature.moh.payload="60" />
<res res.quotas.tone="1000" />

The Wrap Up 

Well there you go, another weird integration issue to add to the list… Hopefully it didn’t wreak too much havoc in your deployments before finding this article. Until next time, happy hacking.

Read more →

Sonus SBC 5k/SWe CDR Decoder

I was on a training course recently learning about the SBC5000/SWe series SBCs from Sonus as these are now supported with Microsoft Lync 2013! This range of SBCs are completely different from the SBC1000/2000 range that you may be used to in your previous Lync deployments. The reason for this difference is that the SBC1000/2000 range were originally designed around a completely different code base by the NET company which was later acquired by Sonus. 

The SBC5000 was  originally designed for large carrier deployments, however, a newer virtualised version of the SBC5000 called the SWe (Software Edition) starts to make these systems much more affordable and interesting for enterprise sized customers. During the training course we were introduced to an online tool that Sonus has for parsing individual Call Detail Records (CDR) to show you what each field in the record represents. This may not sound like much until you see the size of a SBC5000’s CDR record… Behold!

STOP,PRGSBC51,0x000174D700000001,3955074504,GMT,10/22/2014,01:11:19.7,0,4,37,10/22/2014,01:11:40.8,3,2076,16,VoIP,IP-TO-IP,DEFAULT,,,6731234507,,0,,0,,0,,RL7,1,PRGSBC51:TG07,192.168.229.118,192.168.228.237,TG07,,192.168.229.117:1024/10.128.176.185:5062,,192.168.229.117:1026/192.168.228.237:5048,213416,1036,176476,1025,0,,,0x00800000,,,,,2,"SIP,009258DD-F957-E411-8C61-342F2AB2DB43@10.128.176.185,<sip:PhonerLite@10.128.176.185>;tag=3367902045,<sip:6731234507@192.168.229.118>;tag=gK0c816f95,0,,,,sip:6731234507@192.168.229.118,,,,sip:PhonerLite@10.128.176.185:5060,sip:6731234507@192.168.229.118:5060,,,,1,BYE,,0,0,,0,0,,,,,,,,1,0,0,0,,,,,,,,0,,",12,12,0,5,,,0x0a,6731234507,1,1,,1,0,0,0,TG07,"SIP,786432_119514912@192.168.229.118,<sip:PhonerLite@192.168.229.118:5060>;tag=gK0c0170af,<sip:+16731234507@192.168.228.237:5060;user=phone>;tag=4fbfd5e7e6e006f0,0,,,,sip:+16731234507@192.168.228.237:5060;user=phone,,,,sip:PhonerLite@192.168.229.118:5060,sip:+16731234507@192.168.228.237:5060;transport=udp,,,,,BYE,16,0,0,,0,0,,,,,,,,1,0,0,0,,,,,,,,0,,",,110,,,1,1,,,2,P:2:1,P:2:1,10,0x000C0000,,,0,,,,,,0,,,,1,,,,,,,6,,,,,,1,1,1,1,,0,,,1,7,0,2076,1,,,,,192.168.229.118,10.128.176.185,2,16,8,,,,,,,,,0,,,TANDEM,,,10,211150,1025,178192,1036,0,0,0,35,20,,,,,,,13,1,,,,,,,,,,,,,,,,,,,,,0,9,,,,,,,,,,,,,,,"3,39,0,42",0,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,"01,audio,1,G711S,192.168.229.117:1024,10.128.176.185:5062,0:0:0:0,56,G711S,192.168.229.117:1026,192.168.228.237:5048,0:0:0:0,124","01,audio,1,1036,1025,213416,176476,0,0,1025,1036,211150,178192,0,0",0,,,

From this mess you might see how finding field 134 might take some time… So Sonus’ online tool is a very handy thing. The CDR records also contain a great deal of useful information about a call (kind of like Lync Monitoring Database records) such as Codecs Used, if transcoding took place, SBC routes used, reason for disconnection, etc. These records can be extremely useful when troubleshooting issues with the system.

Sonus Online CDR Decoder

I was thinking, though, that you don’t always have access to the internet when you’re working on a customer site, and often you might want to look through a whole file worth of records (instead of cutting and pasting individual records into the online tool). So I decided that it was time once again to get cracking on a Powershell tool for browsing SBC5000 CDR files … and after eleven thousand lines of parsing code I bring you:

Sonus SBC 5k/SWe CDR Decoder

Version 1.0:

• Import SBC5000 or SWe CDR files (ACT files).
• Left hand list view will display all of the records that are in the file.
• Right hand list view displays all of the fields in the selected records.
• Subfields (ie. fields that contain multiple pieces of information in them) are individually broken out and displayed in grey colour.
• Fields are decoded where possible with the decoded value of the field shown in brackets next to the field entry.

Version 1.01 (5/12/2014):

• Added some more enumerations.
• Fixed a few small parser bugs.
• Added a show as text button.

Download Version 1.01:

How to access SBC5000/SWe CDR files

CDR files are also called account files, and they can be easily downloaded from the system via Platform Manager. Simply access Platform Manager (ie. management interface IP on port 444) and go to the Logs -> Event Logs section and select ACT as the log type you wish to access. Then download the file with the Download button:

Then open the Sonus SBC 5k/SWe CDR Decoder tool in Powershell and select the “Browse…“ button, select the ACT file, and click the “Load” button to import the contents of the file. Now you’ll be able to browse the records in the left hand listview and each record you open will be displayed in the right hand listview.

The Wrap Up

At this stage there may not be many deployments of the Sonus SBC5000 or SWe in Lync deployments around the world. However, I can see the SWe being a highly flexible and tenantable virtualised SIP Trunk SBC in the future. So even if this tool doesn’t seem immediately useful it may someday become handy for troubleshooting your future SWe deployments!

Read more →

Power Syslog Server

“My Kingdom for a free and simple syslog server!” – Anonymous System Administrator

So I don’t know about you, but I can’t remember how many times I have got to the point of having to troubleshoot an issue with a Sonus gateway and suddenly remembering I need a Syslog server to get logging out of the box. At this point I usually go and ask Google politely “Google, can you please point me in the direction of a free, and simple, syslog server that I can run without installing a bunch of malware and other rubbish on this nice customer’s server?” At this point Google usually responds “No, I cannot. However, here is a syslog server that requires you install SQL, IIS, and fifteen other dependent services as well as being crippled unless you pay $14.99 per month to a Russian guy name Vlad via this popup window that displays in the middle of the screen every 5 minutes. Also, here’s a Yahoo browser search bar for your trouble.”

This is not an ideal situation… So as usual, I just decided to build it myself. In doing this I sat down and thought about the things I wanted in a simple syslog server, and came up with this list:

• It needs to have no installation process, and leave no trace once removed from a server, as it will be run on customers' servers in a lot of cases.
• It needs to have a display where I can see the messages coming in in real time.
• The messages being displayed must be able to be paused and reviewed, so I can check if a specific event has happened yet.
• The messages window must be able to be cleared so that I can start fresh when trying to troubleshoot a fault.
• The syslog server needs to be able to log to file. Ideally the files should be able to be opened in Sonus LX tool so that further message debugging can be done easily.
• The syslog server needs to be able to roll the log files once they get to a specific size (so they can be emailed, etc).
• The syslog server should only keep a specific number of these log files so that the server’s hard disk does not get filled with log files.
• Both the display and log files should be able to be filtered to display only information that I want to see. For example, only show lines with a specific phone number in them, or only show me SIP messages. These filters should be independent so that you can view the filtered information on screen whilst more detailed information is getting logged to file for further review and troubleshooting later.

Based on these requirements I figured it would be very cool to write the server in Powershell, as this allows for absolutely no installation and can be run on any Windows machine you are likely to run into. How hard could it be?

<Insert training montage>

SMASH CUT:

EXT. TRAINING MONTAGE - THE STAIRS AT THE FRONT OF THE PHILADELPHIA MUSEUM OF ART- DAY

A man in a sweaty hoody runs to the top of a large set of stairs carrying a tablet based productivity device that he is furiously typing on. A large group of the town’s population is also running after him in a large pack for no apparent reason. Upon reaching the top of the steps he punches the air and launches the tablet into the sky. The tablet hits the concrete and smashes into a million pieces. He falls to the ground and screams towards the sky.

MAN

Nooooooo! I should have backed up to the cloud, the cloud I tells ya.

Okay okay, let’s cut to the chase. I did it, and now you too can syslog with me into the sunset.

Power Syslog Server

Version 1.0 Features:

• Zero installation.
• Real time log display (Approximately 1000 lines).
• Copy the displayed text with the Copy Text button. This is useful for more in depth analysis in your favourite notepad software.
• Rolling log files based on file size and number of files to keep.
• Clear display and Pause display functions.
• Filter real-time display logging with regular expression.
• Filter logging to file with regular expression.
• Open firewall for Syslog Server port with the click of a button. If you are not seeing any syslog output in the Power Syslog Server display log then try pressing the Open Firewall button.
• Server listening port can be changed by creating a config file (PowerSyslogServerSettings.cfg) in the same directory as the script. The config file needs to have text in it in the following format "SysLogPort=514". This allows you to maintain the integrity of the code signing by not directly editing the script file.

Version 2.0 Update:

• Added output formatting options to work with Sonus LX tool and AudioCodes Syslog Viewer tool (Commonly used Skype for Business syslog tools used with SBC devices).
• In version 2 if you create a config file named "PowerSyslogServerSettings.cfg" in the same directory as the tool it will use the config file to save all of its settings. The SyslogPort="514" setting remains a hidden setting that can still be used in the config file to change the listening port number.
• UDP socket code has been made more robust to deal with errors when the listening port is being used by another app.
• Changed the font to Courier New for fixed width goodness.
• Fixed issue with rolling files in folders including "." in name and faster processing.

2.01 Bug Fixes (9/8/2017):

• Fixed Sonus LX output formatting to only have LF and not CRLF.
• Increased socket buffer and tuned threading to fix dropped packet issues and double writing of some lines.
• Added disable display checkbox to increase performance when display is not required.

DOWNLOAD HERE

Version 2.0 – Output formats

Version 2.0 of Power Syslog Server now gives you the option to add additional prefix formatting to the start of each line of syslog output. From the research I have done the format of output from each syslog server varies greatly and contains items such as date/time, text based priority field interpretation (ie. The <135> value at the start of syslog messages sent on the wire) and IP Address of the server that sent the message.

The reason that these prefixes are important is that if you want to import the file output back into a tool like Sonus LX or AudioCodes Syslog Viewer to generate call flow diagrams or other features the file needs to be in a format that these tools can interpret. So in order to achieve this, the Format dropdown box has been added in version 2. The Format setting will alter the outputs into the required format for Sonus LX or AudioCodes syslog tools. In addition to these specific tool formats, some other generic prefix formats have been added which will make the output files easier for humans to read.

Output Formats

Format	Example Prefix Format	Comment
None	<No Prefix>	Output syslog in the exact format that it was sent from the device in.
AudioCodes	"17:50:17.588  10.20.2.170     local0.notice"	Output syslog in AudioCodes Syslog Viewer tool format.
SonusLX	"10.20.1.150:53434 <==>"	Output syslog in the same format as the Sonus LX tool.
Level	"Local0.Debug"	Prefix the syslog with the Facility and Severity levels.
DateTime	"2011-10-11 15:00:02.123"	Prefix the syslog with the date and time.
DateTimeLevel	"2011-10-11 15:00:02.123 Local0.Debug"	Prefix the syslog with Date/Time and Facility/Severity.
DateTimeLevelIP	"2011-10-11 15:00:02.123 Local0.Debug    192.168.0.100"	Prefix the syslog with Date/Time, Facility/Severity, and IP Address of the device.

Note: Sonus LX tool cannot open AudioCodes files and AudioCodes syslog tool cannot open LX files. This is because there are special lines of output generated by each brand of SBC that the specific syslog tools use for generating call flow diagrams. So you need to select the correct format for the device and tool you are using if you want to be able to import the files at a later date.

Config File Example

Version 2 can use a configuration file to retain settings that will be applied when the tool boots. When settings are changed within the tool the values will be saved out to the config file. It is important to note that the config file needs to be manually created in order for the tool to start using it. This is deliberate as the config file is for advanced usage scenarios. To create the config file, simply create a text file in the same directory as the script is located and rename the file to "PowerSyslogServerSettings.cfg". Once the file exists the tool will start writing settings to the file. Below is an example of the file format:

SyslogPort="514"

Format="AudioCodes"

LogFile="C:\PowerSyslogFile.cfg"

KeepFiles="2000"

RollFile="20"

Note: Setting values must be surrounded in quote marks. 

How to configure a Sonus Gateway for Syslog Output

Sonus makes some of the most popular Lync Gateways on the market, so I have chosen to use them as an example of how to set up a device to output syslog. Power Syslog Server will work with any other UDP based syslog client as well though, so feel free to use it with other devices too.

Remote Log Servers:

Setup your device to output syslog to the server you are running Power Syslog Server on.  

Global Log Level: If your subsystems are set to “Default” logging level then this setting will be applied to them. This is also the level it will log for all services that are not specified in Subsystems. You will usually set this to a low value like “Error” or “Warning” to avoid log flooding.

Log Destination: The server with the Power Syslog Server running on it.

Port: 514                 

Protocol: UDP

Log Facility: local0

Enabled: Yes

Important Note: When you're finished debugging remember to Disable the syslog output. Otherwise the device will continue to output syslog data over the network, which can be a significant amount of unnecessary overhead for your device, network and server. 

Subsystems:

Then enable the Subsystems as required:

Subsystem: Set the specific Subsystem that you would like to have logged to the syslog output. For troubleshooting call flows and SIP messaging the “SIP Stack Service”, “Common Call Control” (for ISDN translation tables), “Call Routing Service” (for SIP translation tables), and "ISDN Protocol" (for E1 integrations) are useful subsystems to configure here.

Log Level: Set the required Log Level.

Log Destination: The Remote Log Server we created in the first step.

Debugging Log Files in LX Tool

Once you have captured your syslog files using the Power Syslog Server on the server on site you may want to do further call flow debugging using the Sonus LX tool (which can offer you decoded call flows for both SIP and ISDN calls providing your syslog contrains "ISDN Protocol" DEBUG and "SIP Stack Service" DEBUG logging).

To import the file into the LX tool, simply take one of the log files that the Power Syslog Server created and drag it into the LX tool window (or use File->Open). When you do this the LX tool will break the syslog file down into the individual call flows that were captured in the log. Here is an example:

Sonus LX Tool

By double clicking on a call in the "Calls" tab at the bottom of the screen you can get further details on each call flow (including ISDN decoding!):

Sonus LX Tool - Call Flow

Note: The LX Tool is a tool orginally created by NET (which was subsequently acquired by Sonus). To get a copy of the software go to the Sonus Salesforce portal and select "Software Downloads" then select "LX" from the Products list. If you don't have access to the Portal, speak to your Sonus representative to get a copy of the software.

AudioCodes Syslog Viewer

AudioCodes also have a nice Syslog Viewer Tool that can be used with the AudioCodes range of SBCs. The tool has a very nice call flow viewer which gives you a ladder diagram of SIP messages per call which allows you to click on the SIP message to see its contents.

I have found this tool to be much quicker and easier to use in comparison with the Sonus LX tool for troubleshooting SIP related call flow issues. The tool also can accept inputs from multiple devices at once and will put each syslog input into different tabs on the main screen. Using version 2 of Power Syslog Server you can output files into a format that the AudioCodes Syslog Viewer can import and display call flows and multiple device tab windows.

Example Display/Log Filters

Power Syslog Server includes a feature that allows you to filter (using regular expressions) what lines of syslog get displayed on the screen and logged to file. The reason for allowing for having a separate Display Filter and Log Filter is to help you when troubleshooting in real time. By this I mean that you can configure a very specific Display Filter to allow you to see only the messages you want to see for a specific issue and a more general Log File Filter so you can capture more detailed logs to review later in order to pinpoint the exact cause of the issue. Below are some examples of how you can use these filters when troubleshooting issues:

Show Only SIP Messaging

When you are running SIP Stack Service logging at a DEBUG level the Sonus gateway will output all of the SIP messaging that is traversing it. This can be very useful when you need to know what error messages are being sent by the Carrier SIP network or Lync when a call fails.

Example Filter (without quote marks): “sip:”

Example Output:

192.168.0.20 <135>[2014-09-16 00:57:02,709]  287 0002

OPTIONS sip:ux1000lab.mylynclab.com SIP/2.0

FROM: <sip:2013ENTFE003.mylynclab.com:5068;transport=Tcp;ms-opaque=152721d992435f69>;epid=B3F80C5FC7;tag=fb568a1fab

TO: <sip:ux1000lab.mylynclab.com>

CSEQ: 9993 OPTIONS

CALL-ID: 87a0bbd93e7f4e33a2c87ff8bbccd3d7

MAX-FORWARDS: 70

VIA: SIP/2.0/TCP 192.168.0.96:51823;branch=z9hG4bK96df5daa

CONTACT: <sip:2013ENTFE003.mylynclab.com:5068;transport=Tcp;maddr=192.168.0.96>

CONTENT-LENGTH: 0

USER-AGENT: RTCC/5.0.0.0 MediationServer

192.168.0.20 <135>[2014-09-16 00:57:02,718]  322 0001

SIP/2.0 200 OK

Allow: INVITE, ACK, CANCEL, BYE, UPDATE, NOTIFY, OPTIONS, REFER, REGISTER

Call-ID: 87a0bbd93e7f4e33a2c87ff8bbccd3d7

Content-Length: 0

CSeq: 9993 OPTIONS

From:  <sip:2013ENTFE003.mylynclab.com:5068;transport=Tcp;ms-opaque=152721d992435f69>;epid=B3F80C5FC7;tag=fb568a1fab

Server: SONUS SBC1000 3.0.2v270 Sonus SBC

Supported: replaces,update,100rel

To:  <sip:ux1000lab.mylynclab.com>;tag=aedb006-3ef64

Via: SIP/2.0/TCP 192.168.0.96:51823;branch=z9hG4bK96df5daa

192.168.0.20 <135>[2014-09-16 00:57:04,827]  393 0003

OPTIONS sip:siptrunk.aapt.com.au:5060 SIP/2.0

Allow: INVITE, ACK, CANCEL, BYE, UPDATE, NOTIFY, OPTIONS, REFER, REGISTER

Call-ID: call-71280200-0000-0010-1101-0@10.237.176.6

Content-Length: 0

CSeq: 132654 OPTIONS

From:  <sip:Anonymous@10.237.176.6:5060>;tag=aedb006-1

Max-Forwards: 70

Supported: replaces,update,100rel

To:  <sip:Anonymous@siptrunk.aapt.com.au:5060>

User-Agent: SONUS SBC1000 3.0.2v270 Sonus SBC

Via: SIP/2.0/UDP 10.237.176.6:5060;branch=z9hG4bK-UX-0aed-b006-40c88

Show Output Relating to Transformation and Route Rules

This can be extremely useful for troubleshooting what transformation rules a call is using and what routing rule it has chosen.

Example Filter (without quote marks): “regex match|transformation|route request”

Note: You need to be logging at DEBUG level for “Common Call Control” (for ISDN translation tables) and the “Call Routing Service” (for SIP translation tables) for this to work.

Example Output:

192.168.0.20 <134>[2014-09-16 00:51:13,126] 1160 0097 com.sonus.sbc.route INFO (callrouter.cpp:2193) - Handling route request.

192.168.0.20 <135>[2014-09-16 00:51:13,127] 1163 0094 com.sonus.sbc.route DEBUG (translation.cpp:1332) - Performing OPTIONAL transformation using entry Testing Calling Party Rule (13.1(4)).

192.168.0.20 <135>[2014-09-16 00:51:13,127] 1164 0093 com.sonus.sbc.route DEBUG (translation.cpp:649) - Failed regex match of "tfCallingSubNumber" field for "^(9999113\d{2})$" (updated "^(9999113\d{2})$") with input of ""

192.168.0.20 <135>[2014-09-16 00:51:13,127] 1165 0092 com.sonus.sbc.route DEBUG (translation.cpp:1332) - Performing OPTIONAL transformation using entry 4 digit to E.164 (13.2(1)).

192.168.0.20 <135>[2014-09-16 00:51:13,127] 1166 0091 com.sonus.sbc.route DEBUG (translation.cpp:653) - Successful regex match of "tfCalledNumber" field for "^(45\d{2})$" (updated "^(45\d{2})$") with input of "4501"

192.168.0.20 <135>[2014-09-16 00:51:13,127] 1168 008f com.sonus.sbc.route DEBUG (translation.cpp:1332) - Performing OPTIONAL transformation using entry Full National to Lync (13.3(2)).

192.168.0.20 <135>[2014-09-16 00:51:13,127] 1169 008e com.sonus.sbc.route DEBUG (translation.cpp:649) - Failed regex match of "tfCalledNumber" field for "^0(3958245\d{2})$" (updated "^0(3958245\d{2})$") with input of "+61395824501"

192.168.0.20 <135>[2014-09-16 00:51:13,127] 1170 008d com.sonus.sbc.route DEBUG (translation.cpp:1332) - Performing OPTIONAL transformation using entry Local to Lync (13.4(3)).

192.168.0.20 <135>[2014-09-16 00:51:13,127] 1171 008c com.sonus.sbc.route DEBUG (translation.cpp:649) - Failed regex match of "tfCalledNumber" field for "^(958245\d{2})$" (updated "^(958245\d{2})$") with input of "+61395824501"

192.168.0.20 <134>[2014-09-16 00:51:13,127] 1172 008b com.sonus.sbc.route INFO (callrouter.cpp:2396) - Successful route request with entry Analog to Lync (5.1(3))

Show Only Syslog Lines Related to a Specific Phone Number

This can be useful if you know a users telephone number and you only want to see messages that relate to them.

Example Filter (without quote marks): “+61399995555”

The Wrap Up

So there you have it, another tool for the kit bag. I hope you like it and find it useful, I know it’s already got me out of a few close calls. If you find any bugs or have any feature requests feel free to drop me a line.

Read more →