Unity 3.12 and long delay on interview playback

[douglas.wolf]

I have an issue that is only affecting messages (as far as I know) associated with an interview handler playback. When a user resposnible for the interview checks for messages, they often (but not always) get a very long delay before messages will start playing back, sometimes as long as 45 to 60 seconds. There is the following error in the event log:

Zero length Message is detected from User:[Sommer, Ruth] Extension:[8191] Alias:[RSommer] Message#:[1] Invalid MIU stream occurs in Collection index[0] on line 466 of file e:\views\cs_ue3.1.2.41sve\un_Conv1\AvConvSubscriber\AvConvSubMsgPlaySvr\AvSValidMsgStreams.cpp

Running conversation SubMenu on Port 1

Subscriber Display Name : Sommer, Ruth

Subscriber Alias : RSommer

Running conversation SubNewMsgStack on Port 1

Running conversation AvConvSubMsgPlay on Port 1

These are messages from outside the building, and they are being retrieved remotely via dial-in, not outlook. Any suggestions as to where to start to trouble-shoot?

[afuller]

Wow, this is the first time I've ever heard of a customer actually using the interview handlers. There's probably a million undiscovered bugs just due to lack of use.

Do any other users report any delays? The message from the interview handler should be deposited in that mailbox. Does that mailbox ever have problems with any other messages? Take a look at these links for troubleshooting tips:

http://www.cisco.com/warp/public/788/AVVID/16sec_delay_unity.html

http://www.cisco.com/warp/public/788/AVVID/unity-messages-tui.html

adam

[douglas.wolf]

We're a school system, and we use the interview handler for parents calling in the children to be absent, and also for teachers to request a substitute for a particular day. Sorry to hear it's not used much: that means it will that much more difficult to trouble-shoot.

I didn't run the MbxTest utility, but I did double-check and change all the switch settings and nic settings to 100 mbs hard coded. The users experience no other delays in their messages, nor do any other regular users experience any issues. I don't know ho wmany other voicemails they get, though, because they are secretarial staff that routinely answer their phones quickly. I have thought about just blowing up the interview handlers and rebuilding them, but I thought I'd try to fix them first., Strangley, the most delays they experience are on sunday evenings, when there's virtually no one else on the network at school.

[lindborg]

Just because Adam hasn't run into them too often doesn't mean they don't get used ;->

I've run into a _lot_ of sites that use interviewers... hospitals and schools in particular (one hospital I've worked on has over 1,000 in their database) - they work fine, trust me. I'm doubting this has anything at all to do with the interviewers themselves, they're pretty simple objects (less complex than call handlers by a far stretch) - the recording conversation segements are exactly the same as those used all over the system so this is probably not your problem.

I'd be interested in seeing the WAV files one of these messages that's delayed- they're stored as a series of WAV files in the email - I'm curious if perhaps the leading WAV file (i.e. the answer for the first question) is a long period of silence for whatever reason or something along those lines - should be easy to rule out by popping open a message that delayed like this in Outlook and taking a look. Interview handlers don't do the same type of aggressive silence detection time outs that call handlers and subscribers do because the answers are typically very quick and silence timeouts don't come into play. This could be related if there's a big empty message in an answer up front (it's a good idea to "front load" your short answers first and your long winded stuff at the end for this reason).

If the same message plays quickly once and slow another time then it's likely a mailbox retrieval delay issue (not something that would be specific to a message generated by a subscriber, call handler or interview handler)...