TMS and phonebook issue

When I wanted to upload new phonebook error was shown.

Unable to communicate with the Provisioning Extension. See log (log-web.txt) for details.

It looked like all is fine. File is uploaded and accepted but final version was not changed. When I checked directory on server, there was many files so uploading was OK. In logs I found that the problem can be with Cisco TMS Provisioning Extension service.

Fast check and what I found the the service wasn’t started, probably after last restart.

Restart done and nothing changed. Because in my case TMS is in cluster I checked secondary server. It was running but it is cluster I also restarted that service on secondary service.

Cluster-wide service restart solved the problem. New phonebook was uploaded and at the same moment visible at all video terminals.
Phonebooks local directory is C:\Program Files (x86)\TANDBERG\TMS\wwwtms\data\ExternalSourceFiles\

Debugging Q931 – one tip

When I started working at telephony technology first it was easy to debug calls using Q931. I analyzed small systems with small number of calls, so there was no problem to follow one call entire debug.
One day I had to debug a huge cluster with gateway with 4 E1 interfaces and huge amount of calls. Using filters loaded CPU too much so the unique solution was to grab all logs.
The question was “How should I know which line of logs I need to take regarding a call that is interesting for me.
Extracted part of log for one call below:
So first of all we need to catch first part of call with TX -> SETUP, Calling Party Number and Called Party Number. The key info is callref in our case equal 0x1517.

Oct 3 13:18:19.659: ISDN Se0/1/2:15 Q931: TX -> SETUP pd = 8 callref = 0x1517
Sending Complete
Bearer Capability i = 0x8090A3
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98395
Exclusive, Channel 21
Calling Party Number i = 0x0083, '49928853291'
Plan:Unknown, Type:Unknown
Called Party Number i = 0x80, '44344112683'
Plan:Unknown, Type:Unknown
Oct 3 13:18:20.130: ISDN Se0/1/2:15 Q931: RX <- CALL_PROC pd = 8 callref = 0x9517
Channel ID i = 0xA98395
Exclusive, Channel 21
Oct 3 13:18:20.144: ISDN Se0/1/2:15 Q931: RX <- PROGRESS pd = 8 callref = 0x9517
Progress Ind i = 0x8188 - In-band info or appropriate now available
Oct 3 13:18:23.760: ISDN Se0/1/2:15 Q931: RX <- ALERTING pd = 8 callref = 0x9517
Oct 3 13:18:33.109: ISDN Se0/1/2:15 Q931: RX CONNECT_ACK pd = 8 callref = 0x1517
Oct 3 13:18:49.370: ISDN Se0/1/2:15 Q931: RX RELEASE pd = 8 callref = 0x1517
Oct 3 13:18:49.396: ISDN Se0/1/2:15 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x9517

You can see callref is 64bits id in HEX. Within all logs our call transmitting part is with callref = 0x1517. First digit for receiving part is with 8 added. So RX callref is 0x9517.
That’s all.