Dictation stops automatically

[pdurham]

Can anyone help me resolve why my dictation files are being terminated after about five minutes 53 seconds. I have the option set for the files to be sent if the caller hangs up, but for some reason the system is hanging up prior to the caller pressing send.

 

I would like to allow the caller to be able to dictate for at least 30 minutes (legal transcription) without interruption.

 

Also, I have a line with 3 channels (does that mean that I can receive three simultaneous calls?) and if so, how do I set the options to do this. Right now, when a call is active, the line rings busy.

 

Any assistance that anyone would offer would be greatly appreciated.

[sobelman]

Can anyone help me resolve why my dictation files are being terminated after about five minutes 53 seconds. I have the option set for the files to be sent if the caller hangs up, but for some reason the system is hanging up prior to the caller pressing send.

 

I would like to allow the caller to be able to dictate for at least 30 minutes (legal transcription) without interruption.

 

Also, I have a line with 3 channels (does that mean that I can receive three simultaneous calls?) and if so, how do I set the options to do this. Right now, when a call is active, the line rings busy.

 

Any assistance that anyone would offer would be greatly appreciated.

We're having the same problems......Can anyone help us????

 

Thank you.

[blbhs]

We're having the same problems......Can anyone help us????

 

Thank you.

 

I am having the same issue. Calls seem to randomly stop recording.

[Punchy]

I am having the same issue. Calls seem to randomly stop recording.

 

Are your randomly stopping, or stopping specifically at 5 minutes 53?

[kpilcher]

I am having the same issue. Calls seem to randomly stop recording.

 

 

I am having the same issue too . I've traced the VOIP log and it is clear that Dialdictate is unilaterally dropping the call at 5 minutes and 53 or 54 seconds. I've been working with NCH support on this with no success. They are giving me the run-around asking me to perform silly tests and have silly suggestions to try to make it work. They actually suggested that I max out all the timers and remove the voice threshold! That won't fly with my customer or my MT's. I sure hope someone finds the solution soon or I'll be forced to move to another dictation platform.

[Guest nchto]

Those "silly tests" help us determine where the problem is occurring which ultimately means we're able to provide a fix. Please don't complain if you're unwilling to cooperate with us when we were attempting to resolve the problem.

[kpilcher]

I understand that a test should be a tool to provide information that could help you determine the error mode. However, the suggestion that setting all the timers to their maximum value and setting the recording threshold to the minumum value might somehow resolve the issue is not acceptable to anyone.

 

I had a test run from the Callcentric side and they informed me that the absense of RTP packets coming back to them during dictation is the problem. They say that VOIP systems typically disconnect if one or both sides of the conversation is silent (no RTP packes) for too long. They suggest "keepalive" RTP packets or "comfort noise" to keep the connection alive.

 

I hope that we can move forward armed with this information and get the issue resolved. It would make a lot of people very happy with your product.

[kpilcher]

After a lot of testing I have found that if the dictator periodically presses 9 (start dictating from current location) during dictation that the call will not disconnect. The people dictating won't like it but it's better than being disconnected. Let's just hope there is a real solution soon.

[cjessee]

I had the same problem with a standard telephone line - I turned the "Voice Record Activation Level" as far down as I could and I let the hardware take care of the disconnects. This seemed to resolve my problem with a standard telephone line.

[kpilcher]

What happens when the dictator pauses for 2 minutes? I believe it continues to record the silence. Not a good solution.

[kpilcher]

Sorry, correction, what happens when the dictator stops speaking for 2 minutes?

[cjessee]

In my case, using a standard POTS line - I get two minutes of silence. I basically turned the "Voice Activation" off - and made it just record no matter what. It was definitely worth the extra file size. This is probably a different problem than you have - but I wanted to post my solution for the POTS line in the event someone else comes across it.

[abrahamk]

I'm facing the same problem as you all have and I haven't seen any positive reply from any of you, did anyone actually found any solution for this? how have you all dealt with this problem?

[kpilcher]

I was working with NCH for months, well waiting for them to help me... They finally sent me some test software which did not work. Sadly I gave up at that point. I was evaluating their software for a fairly large purchase. While I was going round and round with them I lost my opportunity

 

The issue is relatively simple. Since the dictation conversation is one sided, ie. there is no voice activity from dialdictate. CallCentric sees this inactivity from dialdictate as a probable failure and disconnects the call after a specific time period. This is typical call handling from a lot of VOIP providers. NCH is well aware of this. It is typical for a VOIP software providers like NCH to implement one a number of defacto standard keep alive techniques to prevent this. NCH has chosen to ignore this reality, so here we are...

[cjessee]

I had similar problems as well with DD. Response from NCH was very poor - I had waited 3 months and did not get a response. I e-mailed about once a month to check on the progress and was met with "why do you keep bothering us" response.

[mike@cmd.net]

Those "silly tests" help us determine where the problem is occurring which ultimately means we're able to provide a fix. Please don't complain if you're unwilling to cooperate with us when we were attempting to resolve the problem.

 

I recently switched from using dialogic analog phone lines to Dial Dicate 4.12 with VoIP channels from Callcentric. I've experienced the same problem. I have worked with Callcentric tech support and based on their review of the VoIP log they have concluded that the issue stems from "one-way audio" while dictation is in progress. The VoIP providers to insure the line is not erroneously open if they don’t receive audio or a “RTP keep alive packet” they terminate the connection after certain time period (in our case 5-6 minutes).

 

See below for excerpt of their last response to me.

 

I followed their recommendation to set the “locate the ‘Record voice activation level (dB)’ and set your voice activation level to -30dB”

That did not work. Then I shortened the “Recording continuos auto-stop time” to 320 (just before the disconnect time limit) allowing Dial Dictate to pause and read out the recording “pause mode – press 9 to continue recording”, causing the two-way audio. This keeps the connection and the dictation can continue as long as the caller gets interrupted every 5 minutes and presses 9.

 

BTW, during this test I have resolved that “your voice activation level” setting does not work. Meaning if in pause mode if you start dictating, Dial Dictate does not start recording automatically.

 

My Recommendation:

As seen in the VoIP log below Dial Dictate upon initial INVITE sends the “keep Alive Packet” to both servers. Notice “l:348” (this is exactly the timeout period were the server expects to receive some packet from Dial Dictate).

 

I think Dial Dictate should transmit one of the following after 5 minutes (300 sec):

 

1. Send out “RTP Keep Alive packets” to both servers.

2. Send out a tone.

 

Hope this helps to resolve this problem.

 

 

 

================================================

Thank you for providing your SIP Trace logs onto your account, from your logs, as an example to show the issue, we are taking one call in which abruptly ended after 6 minutes:

 

Here is the initial INVITE packet:

11:55:01 NAT Keep Alive Packet Sent to stun01.sipphone.com

11:55:10 NAT Keep Alive Packet Sent to callcentric.com

11:55:12 UDP Packet Received from 204.11.192.23:5080 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

INVITE sip:17772979347@71.98.252.64:5070 SIP/2.0

v: SIP/2.0/UDP 204.11.192.23:5080;branch=z9hG4bK-2e15492790d6e055ec04bbe2f597f21f

f: <sip:18139266770@66.193.176.35>;tag=3422966101-177815

t: <sip:18139254118@ss.callcentric.com>

i: 499973-3422966101-177765@msw2.telegeny.net

CSeq: 1 INVITE

Max-Forwards: 13

m: <sip:41b874f94b495a5eece665f36a24f316@204.11.192.23:5080;transport=udp>

Supported: timer

c: application/sdp

l: 348

 

v=0

o=NexTone-MSW 2147483647 2147483647 IN IP4 204.11.192.23

s=sip call

c=IN IP4 204.11.192.23

t=0 0

m=audio 58952 RTP/AVP 18 0 8 101

a=fmtp:18 annexb=no

a=fmtp:101 0-15

a=rtpmap:101 telephone-event/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:0 PCMU/8000

a=rtpmap:18 G729/8000

a=ptime:20

a=sendrecv

a=silenceSupp:off - - - -

a=setup:actpass

 

Here is the call being established:

11:55:13 UDP Packet Sent to 204.11.192.23:5080 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

SIP/2.0 200 OK

Via: SIP/2.0/UDP 204.11.192.23:5080;branch=z9hG4bK-2e15492790d6e055ec04bbe2f597f21f

To: <sip:18139254118@ss.callcentric.com>;tag=7709

From: <sip:18139266770@66.193.176.35>;tag=3422966101-177815

Call-ID: 499973-3422966101-177765@msw2.telegeny.net

CSeq: 1 INVITE

User-Agent: NCH Swift Sound Dial Dictate 4.12

Contact: <sip:17772979347@71.98.252.64:5070>

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

Accept: application/sdp

Supported: replaces

Content-Type: application/sdp

Content-Length: 263

 

v=0

o=NCHSoftware-DialDictate 1213973312 1213973316 IN IP4 71.98.252.64

s=Dial Dictate Call

c=IN IP4 71.98.252.64

t=0 0

m=audio 8014 RTP/AVP 0 8 101

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=sendrecv

 

And here is when you call drops after about 6 minutes:

12:01:42 UDP Packet Received from 204.11.192.23:5080 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

BYE sip:17772979347@71.98.252.64:5070 SIP/2.0

v: SIP/2.0/UDP 204.11.192.23:5080;branch=z9hG4bK-19a88ec108849e13ded9e0276a9eb8ee

f: <sip:18139266770@66.193.176.35>;tag=3422966101-177815

t: <sip:18139254118@ss.callcentric.com>;tag=7709

i: 499973-3422966101-177765@msw2.telegeny.net

CSeq: 2 BYE

Max-Forwards: 13

l: 0

 

To address what going above, as we have mentioned previously, your calls are abruptly dropping because our system detected the call as being a call experiencing one-way audio. (this helps prevent issues of mis-billing for calls that only experience one-way audio); which is what you are experiencing.

 

The only recommendation that we can suggest to you is the following:

 

1.) Within the Dial Dictate interface please click on ‘Dial Dictate’ > ‘Options’ > and click on the ‘Options’ tab

 

2.) From there, locate the ‘Record voice activation level (dB)’ and set your voice activation level to -30dB.

 

However if the above mentioned doesn’t work, that this seems to be more of an issue with the software itself and how the software handles its calls; more specifically, it seems that the Dial Dictate software doesn’t send out RTP Keep Alive packets to our servers to prevent our servers from dropping the calls due to one way audio. Due to the limitation of the software itself, there is not much to suggestion except that we recommend that you contact NCH support with regards to the issue at hand as it seems to be an issue with the software.

[Melody A. Nolfi]

I had the same problem with a standard telephone line - I turned the "Voice Record Activation Level" as far down as I could and I let the hardware take care of the disconnects. This seemed to resolve my problem with a standard telephone line.

 

I also have 2 pots lines and randomly (so far seems like after 5 minutes) dial dictate comes on and says "stopped" "please press 9 to dictate" So I unchecked both boxes for end of call detection. What about the recording continuous auto stop time... ?? Mine is on 450 seconds...

 

Any thoughts or suggestions are appreciated

[mike@cmd.net]

I also have 2 pots lines and randomly (so far seems like after 5 minutes) dial dictate comes on and says "stopped" "please press 9 to dictate" So I unchecked both boxes for end of call detection. What about the recording continuous auto stop time... ?? Mine is on 450 seconds...

 

Any thoughts or suggestions are appreciated

 

Melody,

 

Your problem is not the sme as you are using analog phone lines. However what you need to do is to increase your "recording continous auto stip time. 450 is about 7 1/2 minutes after which DD will automatically go to pause mode and read out the messageyou indicated. Set your recording continuous auto stop time = Number of minutes you want as the limit X 60. for example setting it to 1200 will allow up to 20 minutes before going to pause mode.

 

For ALL,

 

I'm happy to let you know that NCH support was able to have their developers come up with a fix. I recieved pre release of fixed version (4.13) this mornning. My intial testing was to dictate 12 minutes of continous recording without any issues.

[Guest nchcc]

Hello All!

Is the problem with DD used with CallCentric?

CallCentric now requires some auto feedback so that they know you are still connected. A version of DD that plays "comfort noise" back to them (CallCentric) when DD is recording is in the works; this version should be out pretty soon!

[cjessee]

Melody,

 

Your problem is not the sme as you are using analog phone lines. However what you need to do is to increase your "recording continous auto stip time. 450 is about 7 1/2 minutes after which DD will automatically go to pause mode and read out the messageyou indicated. Set your recording continuous auto stop time = Number of minutes you want as the limit X 60. for example setting it to 1200 will allow up to 20 minutes before going to pause mode.

 

For ALL,

 

I'm happy to let you know that NCH support was able to have their developers come up with a fix. I recieved pre release of fixed version (4.13) this mornning. My intial testing was to dictate 12 minutes of continous recording without any issues.

 

I'm jealous - I have been waiting for a response since November of 2007.