Hi,

We deployed Teleflow on a customer. Our customer has been very pleased with Teleflow service.

Recently, we notice a error in Teleflow service. Our customer service in just inbound. However an option in Teleflow service allow to connect an inbound call with an external party. The app use "Place Call step". The call are delivered but in teleflow log we detected that Teleflow or NMS are not delivering the correct call result, everything is labeled as BUSY. We think it could be our country pstn has a diferent set of tones for ring, busy, reorder, sit, etc.

Our question is how and where we should adjust tones settings? For example, how to set ring time on/of, ring frequencies, busy, cleardown, etc?

Thanks in advance

Can you provide a log of the call transfer (so, the place call that makes the transfer) and a few steps past it?

Send the log to support@engenic.com, and we will review and respond in this thread.

Reviewing the log, I see you have a Flash Hook for 500 just prior to the Place Call step, which also has a 500ms flash hook built in.

Is this double flash hook intentional? If not, let the Place Call handle the flash, and eliminate the one that comes before the Place Call step.

If it is intentional/necessary to double flash, you might try putting a 500ms Wait step between the Flash Hook step and the Place Call step, and see if this changes anything.

Similarly, I would recommend putting a 500ms Wait step between the BUSY path and the Flash Hook you run after the BUSY occurs. It shouldn't be strictly necessary, but just for good measure, put a Hang Up step just before the new Wait step.

Sometimes, it just comes down to timing.

Hi, thanks for your answer
Yes, the double flash hook is intentional. I we left the place call step only, the 500 ms dont work, the call is not put in hold.

I will try your suggestions. And I will update asap

There might be a faster option to solve this.

If the call transfers properly are working when you get the following results from Place Call:
Setting system variable '@CALLOUT_RESULT' to 'BUSY'
Setting system variable '@CALLOUT_REASON' to 'CLEARDOWN'
you might be able to simply change the handling following the busy a little. You can add a Compare step on the BUSY path to see if @CALLOUT_REASON = CLEARDOWN. If it does, go down the success path from Place Call instead of the current BUSY path.

Before implementing this, you would probably want to do a few tests to make sure that:
1) All successful call transfers on this system result in a CLEARDOWN result.
2) A "real" busy does not get a CLEARDOWN (you'd need to set up a test where you have a call transfer go to a number that would be "BUSY" in the traditional sense).

Hi Chris,

I could some testing. I got this:
1. If I remove hookflash step before place call, the call is not put in hold, seems that place step is not doing the hookflahs correctly in ops0. The log just show:
2013/07/08 13:55:16.078: Event: NCCEVN_CALL_HELD
2013/07/08 13:55:21.078: Event: NCCEVN_CALL_DISCONNECTED, NCC_DIS_NO_DIALTONE
2013/07/08 13:55:21.078: Setting system variable '@CALLOUT_RESULT' to 'FAILURE'
2013/07/08 13:55:21.078: Setting system variable '@CALLOUT_REASON' to 'NO_DIALTONE'
2013/07/08 13:55:21.078: FAILURE

2. I modify the app to trigger a call directly. I got this:
2013/07/08 14:19:20.303: NMS Services:
2013/07/08 14:19:20.303: 0. NCC, ADIMGR, 0, 4:59, 15
2013/07/08 14:19:20.303: 1. ADI, ADIMGR, 0, 4:59, 15
2013/07/08 14:19:20.303: 2. SWI, SWIMGR, 0, 4:59, 15
2013/07/08 14:19:20.303: 3. VCE, VCEMGR, 0, 4:59, 15
2013/07/08 14:19:20.303: Event: CTAEVN_OPEN_SERVICES_DONE, Finished
2013/07/08 14:19:20.303: Using 'ops0' protocol...
2013/07/08 14:19:20.303: Echo canceller not started
2013/07/08 14:19:20.303: Event: NCCEVN_START_PROTOCOL_DONE, CTA_REASON_FINISHED
2013/07/08 14:19:25.319: Event: NCCEVN_CALL_DISCONNECTED, NCC_DIS_NO_DIALTONE
2013/07/08 14:19:25.319: Setting system variable '@CALLOUT_RESULT' to 'FAILURE'
2013/07/08 14:19:25.319: Setting system variable '@CALLOUT_REASON' to 'NO_DIALTONE'
2013/07/08 14:19:25.319: Event: NCCEVN_CALL_RELEASED
2013/07/08 14:19:25.319: u-Event: NCCEVN_CALL_RELEASED
2013/07/08 14:19:25.319: Event: NCCEVN_STOP_PROTOCOL_DONE, CTA_REASON_FINISHED
2013/07/08 14:19:25.319: Event: CTAEVN_DESTROY_CONTEXT_DONE, Finished
2013/07/08 14:19:25.319: Setting system variable '@SYS_CALL_DIRECTION' to 'OUT'
2013/07/08 14:19:25.319: FAILURE


So my questions:
a. Is it possible to disable diatone detection? How I do it?
b. Is it possible to set ringing cadence (and other tones)? How I do it?

a: No. At least, not without TeleFlow Server level changes. This is also highly unlikely to help, and would more than likely create more problems than it will solve.
b: I believe some of what you are suggesting is possible, but I also don't believe it will solve the problem (and is likely again, given most other aspects of your system are working, to create more problems than you are hoping it could solve). Changes of this nature are almost never required.


There are a few things I would recommend trying:

1) My original suggestions of just adding a few waits in in the right places, with your code back to how it was before. I have a feeling this won't work, but if it doesn't, the logs/results may be helpful in determining what would work.

2) The workaround I suggested in the post after the one in which I suggested adding waits. (This has a fairly high probability of just working, given the behavior in the logs, and provided the cleardown is a consistent result for the calls that transfer properly, and not for those that get a legitimate busy)

3) Find out precisely what the TeleFlow lines should be doing for these transfers. Remember that a TeleFlow line in this phone network is really the same as any station sets / phone in the same network. How do they do a transfer? Do they initiate by flash hook? Double flash hook? How long is each flash, if it matters (being digital, I have to wonder)? When you do a transfer like this successfully from a station set, what is the result? (Do you hear a tone or something? It's possible that the reason TeleFlow gets a CLEARDOWN is that this is how the switch/PBX is behaving.)

Hi Chris,

Thanks for your answer.

I would like to try do some tone detection tunning at board level... if it possible just doing settings at config files fo nms board.

I tried your suggestion, adding wait block, It did not help. However, I notice something, even when the second call is succesful, if we try to make this:
caller -> Wait Call -> Play Message -> Hookflash -> Place Call -> Wait -> Play Message -> hangup
The second play message is not triggered.

I think the nms card is misunderstanding the pstn tone cadence and generating a hangup in response. So, I suppose it could worth try to adjust tone cadence detection. Teleflow has step for reorder tone but I wonder if we could do something at board level.

The PBX Alcatel OXE connect to Teleflow using two E1 (60 channels). Each channel behave like an analog line, so we use ops0 protcol. On Alcatel OXE if a analog line want to put a call on hold, it should make a hookflash so it could make a second call or transfer. To recover the initial call, a second hookflash should be done.

Tweaking board-level settings of this nature goes beyond the scope of forums support. If you wish to pursue this yourself, you will need to download the NaturalAccess documentation from Dialogic. (http://www.dialogic.com/manuals)

I still think it is likely this can be solved at the application level. All things considered, if I understand the problem correctly, you might just want to start with this suggestion, and see if it just works: