[SOLVED] 1Kb recordings

[David]

Hello,

We have a problem with call recording. We have 2 different sites - divided per country (Poland and Germany). For each country we have configured own instance of Stream manager and T-server apps. Everything works fine, except one thing. The issue is that actual valid recordings are created only on Polish (PL) site (those recordings are valid audio files). However, the German (DE) site has issues. The files representing recordings are created on the server where Stream manager and T-server apps are hosted, but each recording made at German site has only 1Kb size regardless the call duration was. Also the format of the file is invalid.

We compared Stream Manager logs for 2 calls (faulty DE and correct PL). Here are the log highlights:
* No matter how long DE call lasted, it has always this: (fd=14) recorded 0.0 Kb (30.0 sec) 
* PL calls have always correct details, e.g. PL call has: (fd=19) recorded 935.6 Kb (121.0 sec))
* These 1Kb DE calls have always these timeouts: Inactivity timeout (30.000 sec) for RTPleg[64] 10:07:12.694 Trc 53055 SIPdialog[6] session info 15 (RTP-session-timeout) -- RTP(leg=64):16538
* 1Kb DE calls contain in the log "CSeq: 1 BYE" which is not good
* In Command Sequence (CSeq), the faulty calls contain this reason: Reason: Q.850;cause=127 --> According to manual, cause 127 = CC_CAUSE_INTERWORKING (definition of the reason: Indicates that there has been interworking with a network that does not provide causes for actions it takes. Precise cause cannot be ascertained)

I wonder if you have any idea what could be checked. We use Cisco Unified Communications Manager (CUCM). The firewall is opened between all our hosting servers (both PL and DE) and Cisco Call manager's host.

[Fra]

Hi DM,

If you use a simple CUCM-in-front configuration with CTI integration via T-Server for Cisco , you will have to ask the Cisco engineers to do some proper tracing on their side to have a better understanding of what happens.
Although the reason code you posted seems to point to interworking issues, it might be a red herring and simply a generic error condition.
If you have the firewall between your Stream Manager and the Cisco, well, have a network trace done that too...personally, I never trust firewall engineers, there is always at least one port they forgot to open...

Fra

[jamesmurphyau]

Might not be your problem but I've seen a stream manager fill a directory with 1kb files when the disk is full - it appears it could still create the blank file

[cavagnaro]

Well seems logic. As said, a port issue
As there is no RTP traffic sent to SM then it doesn't record nothing. As SM states, a interworking issue. I also never trust network guys, it is never their fault, they are perfect, until it is 90% times their fault. What you can do is run a wireshark on the server and capture Rtp traffic, you will see it is none...

[David]

Hi,

You were absolutely right! The firewall was closed between IP phone subnet and physical server hosting Stream manager app, connection between CUCM and Stream manager was already opened. Now recordings are created.

Big thanks for the advice!

[Fra]

excellent