Outbound Call Can't Be Made If Inout Shows "in"

[Guest u4910]

Sometimes on of the lines in the status will show "in" on inout and it will not make an outbound call until I hang up the line in the line status.

The last outbound call hangs up, so I'm not sure what the issue is.

Please advise.

0101_1006_vgEngine.txt

0101_ktTel.txt

0101_ktTts.txt

[SupportTeam]

Please update to this new version of VoiceGuide: [old link removed]

This version fixes the bug that you have encountered (caused by incoming calls which were not being answered by your system).

If you still encounter problems please post traces as before.

[Guest u4910]

OK, I installed 7.0.9 and that seems to have taken care of the "in" problem. It also has taken care of the issue with dialing out and it thinks there is a SIT tone when there is not.

But now it plays a wav file on outgoing calls but will not hang up. Also the line status monitor will not allow me to manually hang up the line.

Is there a known issue with these two last things in 7.0.9?

[SupportTeam]

Please update to this version: [old link removed] and post traces if you encounter problems.

[Guest u4910]

OK, I installed that version and now:

It is back to not being able to dial on the one line (like in 7.0.8)

It will play the wav file and hang up.

I notice that I cannot forceably hang up the line like in 7.0.8.

I notice that after I made the first outound call the next one would not dial until I stopped the service and restart. I noticed this behavior in 7.0.8, but I could hand up using the line monitor.

0103_ktTel.zip

0103_0946_vgEngine.txt

[Guest u4910]

This is a little frustrating to troubleshoot. The line that is not working, seems to fail on all outbound calls. It takes inbound calls fine. I have switched ports on the card and same results.

The line that works, seems to work fine all the way around.

I have a handset and tested on each line. The bad line sounds fine and I can make calls from the handset fine.

Any ideas? I really want the "bad" line to work since that is the primary line that I will use.

[SupportTeam]

Traces show that the Dialogic card is still detecting SIT (Tri-tones) when some of the outgoing calls are made.
Traces also show that this Dialogic card is detecting a ring signal immedialtey after hanging up the call (on some calls). This is usually a sign of an impedance mismatch on the lines, so this again points to a problem with the lines.

Please update to this new version: [old link removed]

This new version should report the SIT details, and also should handle the false ring signal better so that it's presence does not interfere with further outgoing calls being made on this line.

[Guest u4910]

Thank you so much for your efforts. I'll give this a try and let you know. I hope you all had a Happy New Year!

[Guest u4910]

Cool! I think it's all working now. I'll do some more testing and let you know tomorrow.

Thank you all so much!!

[SupportTeam]

If you encounter more SIT (Tri Tones) on the outgoing calls please post the VoiceGuide traces - in those traces we should now be able to see what are the frequencies of the 3 tones and this should let you find out what is the actual error code that the PBX/Switch is sending to the Dialogic card when it tries to make the call.

[Guest u4910]

OK, still not perfect. It worked on the "bad" line the first time and after making some repeated outbound calls on this line, I notice "LsWaitAfterDialingOut" in the monitor and the log file.

I'm not sure exactly what is happening, so I've attached the traces.

0103_ktTel.zip

0103_2231_vgEngine.txt

[SupportTeam]

Did you perhaps see this in the status display:

 

Hanging up... [CR_CEPT in LsWaitAfterDialingOut]

 

Which means that the call is being ended as the Dialogic card detected a SIT (the tri-tone) on the line.

The above state would show for about a second or so and then you should see the state change to:

 

Waiting for a call...

 

And about a second later a new outgoing call could be made on the line again, which then again may get a SIT reported by Dialogic.

 

I think what you are seeing here is not any error but VoiceGuide simply reporting that Dialogic heard a SIT tone of the outgoing calls after finishing dialing the number and the call was therefore ended. And each call displays the Hanging up... [CR_CEPT in LsWaitAfterDialingOut] status message at hangup time.

[Guest u4910]

Were you able to see the values for the frequencies of the 3 tones? I'm curious what they are. When I record outgoing calls using the record module, like you had suggested before, I didn't hear the SIT tone.

[SupportTeam]

The card is not reporting all 3 tones. Only one (around 910Hz). Not sure why that is.

 

Is the Dialogic card now reporting that it hears the SIT every time the call is placed on a particular line, or only sometimes? If all the time then you should be able to hear the tone when just attaching the line to a normal analog phone and placing the call yourself.

[Guest u4910]

I restarted the service and made one call, and it did the same thing. Attached are the logs. I see the SIT tone being reported and I see just the one 906hz. When I make a call with the handset, it works and sounds fine. Any ideas? Is there a way to have it ignore this type of issue with what it "thinks" is a SIT tone but not really?

0104_ktTel.txt

0104_1552_vgEngine.txt

0104_ktTts.txt

[SupportTeam]

How many lines are used on this system? Is this the only line on which this problem is occurring, or does it occur on all the lines? Have you tried using the problem line in other ports on the Dialogic card? The problem may also be Dialogic card port related.

 

How often does this problem occur? Traces show that you are able to make some outgoing calls, so do the other lines/ports work OK?

 

Is there a way to have it ignore this type of issue with what it "thinks" is a SIT tone but not really?

The SIT tone detection ends Dialogic's answer detection, so the card is not longer able to report when the call is actually answered, or whether the call is answered by a human or answering machine. We may be able to do a workaround for this but this would involve a custom modification to the software - to basically perfom one 'dummy' dial and then another proper dial, but there is no guarantee that this would work if the problem is with the Dialogic port itself.

[Guest u4910]

I have two phone lines (numbers) that I am using. The primary and secondary. The primary seems to be the problem. I have switched the lines on the ports and the behaviour is the same. It seems to be related to the line and not the port. I'll try port three and four.

[SupportTeam]

It seems to be related to the line and not the port.

It is possible that that line has some impedance mismatch with the Dialogic board and that is why you are seeing these problems when attaching the line to the Dialogic card and not when attaching the line to the normal analog phone.

 

Probably best to ask the Telco to check out this line and for now just use the line that works without these problems.

[Guest u4910]

OK. I tried port 4 on my dialogic card and the "bad" line seems to be working fine! I don't know why I didn't try evey port combination. Port 1 and 2 seem bad (even though they work for the other line).

So, I'll return the card for an exchange.

Thank you so much for helping with this. I think I'm good to go now.

[SupportTeam]

OK. I tried port 4 on my dialogic card and the "bad" line seems to be working fine! I don't know why I didn't try evey port combination. Port 1 and 2 seem bad (even though they work for the other line).

So, I'll return the card for an exchange.

Thank you so much for helping with this. I think I'm good to go now.

Thanks for giving us and other readers the update.

[Guest u4910]

Sure. Some problems are too strange to explain. I'm still not sure why the one line works on ports 1 & 2 while the other does not.

But, whatever works. I'll see how the new card goes.

BTW, when I get the exchanged Dialogic card, do I request a new license key at that point from VoiceGuide?

[SupportTeam]

Please contact sales@voiceguide.com regarding the license enquiries.

[Guest u4910]

Well, it is just a no go. The port 4 that I thought was working now will not make a successful call.

I swapped out the dialogic card for another one and the same thing. I just can't make this "bad" line work and I don't hear any noise and can make calls with a handset.

Please advise.

[SupportTeam]

So you have one line that works with no problems regardless of what Dialogic port it is attached to and you have one line that has problems regardless of what Dialogic port it is attached to, correct?

 

If the problems are line related then you should speak to the telephone line provider and ask them to test that line.

[Guest u4910]

Ok now I had some problems with the other line getting a SIT tone that is not really a SIT tone. I called the telco and they say the lines are fine.

Is there any way to get the Dialogic card to ignore the kind of tone that it is thinking it is hearing dialing out. I think it hears 900hz, 0hz, 0hz. You had mentioned a customization of some kind to take care of this?

 

[SupportTeam]

The problem here is either with the Dialogic card or with the phone lines (or a combination of both).

 

We could change the software to ignore this tone, and restart detection for answer again, but this would be a custom modification to address what is being reported here. Hard to say whether the answer detection restart will actually fix anything here, as we are working with card/lines that are already giving us unexpected results.

 

To enquire about software customization please contact sales@voiceguide.com and include the link to this thread in your email.

[Guest u4910]

OK I'm still struggling. I can't make either of my lines work. I had the phone company come out and fix a "crossover issue" with the lines, but I am still getting "SIT tone: [906Hz 0ms | 0Hz 0ms | 0Hz 0ms]".
There _has_ to be a way to ignore this. It happens at the moment it finishes dialing and then it hangs up. So it won't make a call at all. From a handset, I don't hear any problems.




210304.194 6124 7 ev TDX_CALLP (Call Progress Completed)

210304.194 6124 7 TDX_CALLP CR_CEPT (called line received operator intercept (SIT). The Extended Attribute functions provide information on the detected frequencies and durations)

210304.194 6124 7 SIT tone: [906Hz 0ms | 0Hz 0ms | 0Hz 0ms]

210304.194 6124 7 ATDX_CRTNID did not supply further information. must be a Springware board. tone_id=0

210304.194 6124 7 raise Dialogic TDX_CALLP 133 (11 0 0 CR_CEPT 906Hz 0ms | 0Hz 0ms | 0Hz 0ms )

210305.205 2900 7 fn DropCall(sLineId=7, sXMLOptions=[], iParam1=0)


-------------------------

[SupportTeam]

Do you need for the system to be able to detect call answer? Maybe you could start the outgoing script immediately after the number is dialed and have the script start with a module that repeats (many times) a "Please press 1 to accept this call" message. Then when person answering the call presses "1" the script can go on to next module. This approach would of course not be able to handle answering machines.

 

Just specify:

 

Disabled

 

in the Answerng Machine Script text box to disable the Dialogic card answer detection.

 

Also, as per our previous post:

We could change the software to ignore this tone, and restart detection for answer again, but this would be a custom modification to address what is being reported here. Hard to say whether the answer detection restart will actually fix anything here, as we are working with card/lines that are already giving us unexpected results.

 

To enquire about software customization please contact sales@voiceguide.com and include the link to this thread in your email.

[Guest u4910]

I think I am seeing the light at the end of the tunnel. I had the idea to get a DSL line filter thinking that the 906hz is basically a hum on the line, which I can actually hear a little. So I got one and that seems to help. I can actually make outbound calls about 75% of the time now with only 25% SIT error rate. I also can hear cross talk still on my two lines, so I'm going to have the telco do an inside test to test from the handset versus just testing the outside connection.