Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Avaya IP Office Recordings randomly stop

Status
Not open for further replies.

fillthy

IS-IT--Management
May 11, 2006
75
CA
Hi all, I have Avaya IP Office 4.2.14 / VoiceMail Pro 4.2.30. I have enable inbound recordings for a bunch of users/ext's. The recordings all start no problem but they all cut of at random times. I have set the max to 3600 seconds..But my recordings will be anywhere from 1-5 minutes (then drop) even though they should be 10-20 minutes in length..I installed Contact Store and its the same in there..The calls are not recording for the full duration of the call.
Any ideas?
Cheers
 
Wish I could help but I haven't had much experience with failed recordings. Have you tried to backup your call flows and reinstall VM Pro - or even do a complete system rebuild - testing for memory and other hardware errors? I know that sounds extreme but this is a Windows box I believe we are talking about. Also do regular voicemail messages fail at random times also or only "inbound recording"? is it a VM Pro dedicated server?
 
1 st question like Tom asked..do regular voicemail messages fail at random times also or only "inbound recording"? is it a VM Pro dedicated server?

is the VM pc/ server plugged dierectly into IP office?/

If not maybe check the setting on the network ports and PC


ACS- IPOffice Implement
 
Hi, the IP Office Manager and VoiceMail Pro are both on the same Windows 2003 R2 dedicated server. No, messages do not fail, just inbound recordings. Even if I do a manual inbound recording it fails to record the full conversation. I have our Avaya service guys on this and they are stumped at why its happening. Do you think a full re-install (VoiceMail Pro)would fix?
Cheers
 
You should look carefully at sysmon and dbgtrace traps to find a trigger for the drops.
 
Is the VM server connected directly to the IP Office or are they connected through a network switch? If it is a network switch check the port settings make sure they are same for both the IP Office and VM.. I have seen some wierd problems when the is a port mismatch or ports are set for Auto..

ACS- IPOffice Implement
 
Hi, they are both plugged into a switch (Gigabit) I guess I'll have to look into those tools you mention...
Cheers
 
dbgtrace will tell you when a recording starts and stops. don't be afraid. try it.
 
I cannot find dbgtrace on my server 2003...Where/how does one get this?
 
Thanks, heres some output right before the recording stops:

01/09 10:55:04.390 vmprov5s (06,8) a64,1a1c: > VMUser::CommandBuffer(buf: 03FC01E0, sequencing=true)
01/09 10:55:04.390 vmprov5s (06,8) a64,1a1c: < VMUser::CommandBuffer()
01/09 10:55:04.390 vmprov5s (06,8) a64,1a1c: < VMClient::Transfer()
01/09 10:55:04.390 vmprov5s (06,9) a64,1a1c: > IUser::RemoveClient(Client<0BC45924> )
01/09 10:55:04.390 vmprov5s (06,9) a64,1a1c: < IUser::RemoveClient()
01/09 10:55:04.390 vmprov5s (06,5) a64, 4d8: VMClient::StalledReceiver 0C678150 (session 0000036e)
01/09 10:55:04.390 vmprov5s (09,4) a64, 4d8: Session: 0000036e - Stalled Receiver for session 0000036e (object 0C678150)
01/09 10:55:04.390 vmprov5s (09,4) a64, 4d8: Session: 0000036e - Requesting disconnect [attempt 1] for Voicemail Client (VMClient object=0C678150, session=0000036e)
01/09 10:55:04.390 vmprov5s (06,8) a64, 4d8: > VMClient::Transfer(TIMEOUT, FALSE)
01/09 10:55:04.390 vmprov5s (06,8) a64, 4d8: > VMUser::CommandBuffer(buf: 03FBF3F8, sequencing=true)
01/09 10:55:04.390 vmprov5s (06,8) a64, 4d8: < VMUser::CommandBuffer()
01/09 10:55:04.390 vmprov5s (06,8) a64, 4d8: < VMClient::Transfer()
01/09 10:55:04.390 vmprov5s (06,9) a64, 4d8: > IUser::RemoveClient(Client<0C6781EC> )
01/09 10:55:04.390 vmprov5s (06,9) a64, 4d8: < IUser::RemoveClient()
01/09 10:55:04.390 vmprov5s (06,5) a64,1524: VMClient::StalledReceiver 0BBF5058 (session 00000379)
01/09 10:55:04.390 vmprov5s (09,4) a64,1524: Session: 00000379 - Stalled Receiver for session 00000379 (object 0BBF5058)
01/09 10:55:04.390 vmprov5s (09,4) a64,1524: Session: 00000379 - Requesting disconnect [attempt 1] for Voicemail Client (VMClient object=0BBF5058, session=00000379)
01/09 10:55:04.390 vmprov5s (06,8) a64,1524: > VMClient::Transfer(TIMEOUT, FALSE)
01/09 10:55:04.390 vmprov5s (06,8) a64,1524: > VMUser::CommandBuffer(buf: 03FC0D00, sequencing=true)
01/09 10:55:04.390 vmprov5s (06,8) a64,1524: < VMUser::CommandBuffer()
01/09 10:55:04.390 vmprov5s (06,8) a64,1524: < VMClient::Transfer()
01/09 10:55:04.390 vmprov5s (06,9) a64,1524: > IUser::RemoveClient(Client<0BBF50F4> )
01/09 10:55:04.390 vmprov5s (06,9) a64,1524: < IUser::RemoveClient()
01/09 10:55:04.390 vmprov5s (11,8) a64, c90: < TFTPTask::processReceiveBuffer()
01/09 10:55:04.390 vmprov5s (11,9) a64, c90: < TFTPDevIOTask::processReceiveBuffer()
01/09 10:55:04.390 vmprov5s (09,5) a64, c90: Took 11860ms to process message
01/09 10:55:04.390 vmprov5s (0b,9) a64,1c64: VMRegistry::GetRegistryEntry(00000184, SeqTimeout) returning "3500"
01/09 10:55:04.390 vmprov5s (06,9) a64,1c64: < VMUser::SendSeq()
01/09 10:55:04.390 vmprov5s (06,8) a64,1c64: < VMUser::CommandBuffer()
01/09 10:55:04.390 vmprov5s (06,8) a64,1c64: < VMClient::Transfer()
01/09 10:55:04.390 vmprov5s (06,9) a64,1c64: > IUser::RemoveClient(Client<0BD64124> )
01/09 10:55:04.390 vmprov5s (06,9) a64,1c64: < IUser::RemoveClient()
01/09 10:55:04.390 vmprov5s (0b,9) a64,1c64: VMClient::play (Exiting as !ThrottledTxData)
01/09 10:55:04.390 vmprov5s (06,9) a64,1c64: < VMClient::play()
01/09 10:55:04.390 vmprov5s (0b,9) a64, a7c: VMRegistry::GetRegistryEntry(00000184, MinimumIdleTime) returning "2400000"
01/09 10:55:04.390 vmprov5s (0b,9) a64, a7c: VMRegistry::GetRegistryEntry(00000184, TraceVoicemailUsage) returning "N"
01/09 10:55:04.390 vmprov5s (06,9) a64, bb4: > VMUser::processSequencedData(buf=040DAA68, tx_seq=594, rx_seq=4481)
01/09 10:55:04.390 vmprov5s (06,9) a64, bb4: > VMUser::RecvAck(594)
01/09 10:55:04.390 vmprov5s (06,9) a64, bb4: > VMUser::SendSeq(tx_seq=595, sequencer_attempts=0)
01/09 10:55:04.390 vmprov5s (0b,9) a64, bb4: VMRegistry::GetRegistryEntry(00000184, SeqTimeout) returning "3500"
01/09 10:55:04.390 vmprov5s (06,9) a64, bb4: < VMUser::SendSeq()
01/09 10:55:04.390 vmprov5s (06,9) a64, bb4: < VMUser::RecvAck()
01/09 10:55:04.390 vmprov5s (06,9) a64, bb4: < VMUser::processSequencedData()
01/09 10:55:04.390 vmprov5s (0c,8) a64,1a1c: > IClient::UnLink(No Vtable=no)
01/09 10:55:04.390 vmprov5s (0c,6) a64,1a1c: Unlinking Voicemail Client (IClient object=0BC45924, session=00000370)
01/09 10:55:04.390 vmprov5s (09,4) a64,1a1c: Session: 00000370 - EndRecording
01/09 10:55:04.390 vmprov5s (21,8) a64,1a1c: > DiskSpaceAlarm::AnalyseDiskSpaceAvailable(File: D:\Program Files\Avaya\IP Office\Voicemail Pro\VM\Accounts\TechHelpPCR\MSG01133.WAV)
01/09 10:55:04.390 vmprov5s (0b,9) a64,1a1c: VMRegistry::GetRegistryEntry(00000184, SnmpAlarmCritical) returning "50"
01/09 10:55:04.390 vmprov5s (0b,9) a64,1a1c: VMRegistry::GetRegistryEntry(00000184, SnmpAlarmLevel) returning "60"
01/09 10:55:04.390 vmprov5s (0b,9) a64,1a1c: VMRegistry::GetRegistryEntry(00000184, SnmpAlarmOk) returning "90"
01/09 10:55:04.390 vmprov5s (21,8) a64,1a1c: > DiskSpaceAlarm::SetCurrentDiskState()
01/09 10:55:04.390 vmprov5s (21,8) a64,1a1c: < DiskSpaceAlarm::SetCurrentDiskState()
01/09 10:55:04.390 vmprov5s (21,8) a64,1a1c: > DiskFreeState::AnalyseDiskState()
01/09 10:55:04.390 vmprov5s (21,8) a64,1a1c: < DiskFreeState::AnalyseDiskState()
01/09 10:55:04.390 vmprov5s (21,8) a64,1a1c: < DiskSpaceAlarm::AnalyseDiskSpaceAvailable()
01/09 10:55:04.406 vmprov5s (1f,8) a64,1a1c: > VMailBox::UpdateFileState(Mailbox: TechHelpPCR, Msg: MSG01133, State: New)
01/09 10:55:04.421 vmprov5s (1d,8) a64,1a1c: > tblMailbox::LocateMessage(Mailbox ID:{002365A6-0249-487B-978D-36DA23539675}, Message Number:1133)
01/09 10:55:04.421 vmprov5s (1d,8) a64,1a1c: Query: SELECT ID FROM Message WHERE MessageNumber = ? AND MailboxID = ?
01/09 10:55:04.453 vmprov5s (1d,5) a64,1a1c: Information: No data found executing SQLFetch (line 2446, file ".\tblMailbox.cpp")
01/09 10:55:04.453 vmprov5s (1d,8) a64,1a1c: < tblMailbox::LocateMessage()
01/09 10:55:04.453 vmprov5s (06,8) a64,1a1c: > VMailBox::SendMailboxInfo(Name: TechHelpPCR, New: 191, [Unopened: 0], Old: 0, Saved: 0)
01/09 10:55:04.453 vmprov5s (0c,8) a64, 4d8: > IClient::UnLink(No Vtable=no)
01/09 10:55:04.453 vmprov5s (0c,6) a64, 4d8: Unlinking Voicemail Client (IClient object=0C6781EC, session=0000036e)
01/09 10:55:04.453 vmprov5s (09,4) a64, 4d8: Session: 0000036e - EndRecording
01/09 10:55:04.453 vmprov5s (21,8) a64, 4d8: > DiskSpaceAlarm::AnalyseDiskSpaceAvailable(File: D:\Program Files\Avaya\IP Office\Voicemail Pro\VM\Accounts\xxxxxxxxxx\MSG00480.WAV)
01/09 10:55:04.453 vmprov5s (0b,9) a64, 4d8: VMRegistry::GetRegistryEntry(00000184, SnmpAlarmCritical) returning "50"
01/09 10:55:04.453 vmprov5s (0b,9) a64, 4d8: VMRegistry::GetRegistryEntry(00000184, SnmpAlarmLevel) returning "60"
01/09 10:55:04.453 vmprov5s (0b,9) a64, 4d8: VMRegistry::GetRegistryEntry(00000184, SnmpAlarmOk) returning "90"
01/09 10:55:04.453 vmprov5s (21,8) a64, 4d8: > DiskSpaceAlarm::SetCurrentDiskState()
01/09 10:55:04.453 vmprov5s (21,8) a64, 4d8: < DiskSpaceAlarm::SetCurrentDiskState()
01/09 10:55:04.453 vmprov5s (21,8) a64, 4d8: > DiskFreeState::AnalyseDiskState()
01/09 10:55:04.453 vmprov5s (21,8) a64, 4d8: < DiskFreeState::AnalyseDiskState()
01/09 10:55:04.453 vmprov5s (21,8) a64, 4d8: < DiskSpaceAlarm::AnalyseDiskSpaceAvailable()
01/09 10:55:04.453 vmprov5s (1f,8) a64, 4d8: > VMailBox::UpdateFileState(Mailbox: xxxxxxxxxx, Msg: MSG00480, State: New)
01/09 10:55:04.453 vmprov5s (1d,8) a64, 4d8: > tblMailbox::LocateMessage(Mailbox ID:{EA823F6D-4D84-47AD-B60B-C29EF766A99A}, Message Number:480)
01/09 10:55:04.453 vmprov5s (1d,8) a64, 4d8: Query: SELECT ID FROM Message WHERE MessageNumber = ? AND MailboxID = ?
01/09 10:55:04.468 vmprov5s (1d,5) a64, 4d8: Information: No data found executing SQLFetch (line 2446, file ".\tblMailbox.cpp")
01/09 10:55:04.468 vmprov5s (1d,8) a64, 4d8: < tblMailbox::LocateMessage()
01/09 10:55:04.468 vmprov5s (06,8) a64, 4d8: > VMailBox::SendMailboxInfo(Name: xxxxxxxxxx, New: 1, [Unopened: 0], Old: 0, Saved: 0)
01/09 10:55:04.468 vmprov5s (0c,8) a64,1c64: > IClient::UnLink(No Vtable=no)
01/09 10:55:04.468 vmprov5s (0c,6) a64,1c64: Unlinking Voicemail Client (IClient object=0BD64124, session=00000380)
01/09 10:55:04.468 vmprov5s (0c,9) a64,1c64: > VMDialog::Close()
01/09 10:55:04.468 vmprov5s (00,9) a64,1c64: > CPool::put()
01/09 10:55:04.468 vmprov5s (00,9) a64,1c64: < CPool::put()
 
Does this mean it thinks we are out of room (storage) we have 200GB free on the drive that saves recordings:


01/09 11:15:43.663 vmprov5s (0c,6) a64,1a20: Unlinking Voicemail Client (IClient object=0BC45924, session=000003e4)
01/09 11:15:43.663 vmprov5s (09,4) a64,1a20: Session: 000003e4 - EndRecording
01/09 11:15:43.663 vmprov5s (21,8) a64,1a20: > DiskSpaceAlarm::AnalyseDiskSpaceAvailable(File: D:\Program Files\Avaya\IP Office\Voicemail Pro\VM\Accounts\xxxxxx\MSG03212.WAV)
01/09 11:15:43.663 vmprov5s (0b,9) a64,1a20: VMRegistry::GetRegistryEntry(00000184, SnmpAlarmCritical) returning "50"
01/09 11:15:43.663 vmprov5s (0b,9) a64,1a20: VMRegistry::GetRegistryEntry(00000184, SnmpAlarmLevel) returning "60"
01/09 11:15:43.663 vmprov5s (0b,9) a64,1a20: VMRegistry::GetRegistryEntry(00000184, SnmpAlarmOk) returning "90"
01/09 11:15:43.663 vmprov5s (21,8) a64,1a20: > DiskSpaceAlarm::SetCurrentDiskState()
01/09 11:15:43.663 vmprov5s (21,8) a64,1a20: < DiskSpaceAlarm::SetCurrentDiskState()
01/09 11:15:43.663 vmprov5s (21,8) a64,1a20: > DiskFreeState::AnalyseDiskState()
01/09 11:15:43.663 vmprov5s (21,8) a64,1a20: < DiskFreeState::AnalyseDiskState()
01/09 11:15:43.663 vmprov5s (21,8) a64,1a20: < DiskSpaceAlarm::AnalyseDiskSpaceAvailable()
01/09 11:15:43.663 vmprov5s (1f,8) a64,1a20: > VMailBox::UpdateFileState(Mailbox: xxxxxxxxx, Msg: MSG03212, State: New)
01/09 11:15:43.663 vmprov5s (1d,8) a64,1a20: > tblMailbox::LocateMessage(Mailbox ID:{4948F146-039B-48F9-AA59-8459BB8BDEAB}, Message Number:3212)
01/09 11:15:43.663 vmprov5s (1d,8) a64,1a20: Query: SELECT ID FROM Message WHERE MessageNumber = ? AND MailboxID = ?
01/09 11:15:43.679 vmprov5s (1d,5) a64,1a20: Information: No data found executing SQLFetch (line 2446, file ".\tblMailbox.cpp")
 
The logs says you have a disk space alarm
Do you have contact store perhaps ?
Does that partition have enough space ?


RTFM.gif



ACS - Implement IP Office
ACA - Implement IP Telephony -- ACA - Design IP Telephony
ACA - Voice Services Management
______________
Women and cats can do as they please and men and dogs should relax and get used to the idea!
 
Yes we also have contact store. It doesn't matter where the recordings go (Voicemail Pro default dir or ContactStore dir) they still drop. Both directories/disks have plenty of space (200+ GB) Why would the logs think we have a disk issue? Would you think a removal and re-install of Voicemail Pro would help?
 
You could try to do that
But do you have 200 GB free on the C partition ?
And how many do you have free on the D partition ? (contact store)


RTFM.gif



ACS - Implement IP Office
ACA - Implement IP Telephony -- ACA - Design IP Telephony
ACA - Voice Services Management
______________
Women and cats can do as they please and men and dogs should relax and get used to the idea!
 
No, IP Office manager and Voicemail Pro are on the same server (2003) there is 1.5GB free on the C: drive and 200GB+ free on the D: drive. Voice Mail Pro was installed on the D: drive and all working directories are located on this 200GB D: Contact store is a different server (2003) and has 500GB+ on its recording drive setup in Contact Store. But even when I dont have IP Office Manager send to Contact Store (Voice Recording Library Auto unchecked) It still drops the recordings..Could the C: drive only having 1.5GB have something to do with it? I inherited this server from the previous tech..I would have made sure the C: had plenty of space ;)
Cheers
 
Strange, try a reinstall or repair

RTFM.gif



ACS - Implement IP Office
ACA - Implement IP Telephony -- ACA - Design IP Telephony
ACA - Voice Services Management
______________
Women and cats can do as they please and men and dogs should relax and get used to the idea!
 
I don't think the trace is showing a disk full alarm. I think that bit just shows it carried out a disk space availability test before it started the recording. At least thats what it looks like on my system, which is recording just fine.

There are two things I think are odd on your trace,
1) Stalled Recievers
2) Took 11860ms to process message

but the snippets are too small to see what was happening on those calls prior. If I could make sense of the trace I'd be interested to know what messaage took nearly 12 secs to process, and whether these events are always present on the dropped recordings. I would guess these events are only seen on unsuccessful recording attempts.
 
Thanks, I will look at that Taurean. I did a full re-install last night of VoiceMail Pro. I did this around 1am when I was the only one in the office (I don't sleep) I made a successful recording of 30 minutes which I've never been able to do. I thought I had solved the issue with the re-install. Then when I came in this morning they were dropping again after 2 minutes! Of course we are busy this morning as opposed to last night. We have plenty of VM channels free though.
Cheers
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top