Hi, <br> <br>Im running an app with a 4 Port - D/4PCI card but it doesn't recognize <br>when user hangs up. <br>I can see on teleflow monitor when a call is answered, but if I hang up the port still runs the app. <br> <br>How can I fix this?

This is because there is no hang up supervision on the lines you are using. If you can get hang up supervision on those lines, this problem will go away. <br> <br>Alternatively, here are two things you can do: <br>1) Timeouts: Make sure that no matter where in the system your caller is, if they don't enter any information in, you let them try again. After a couple of tries, have the system disconnect them politely. (ie. "We're sorry you're having difficulties. Please try again later. Goodbye.") Make sure that your lines are in a hunt group, so that when a line remains busy, your call is forwarded to the next line. <br>2) Set Reorder: Use the Set Reorder Tones step in your application. You would have to find and set the parameters for the step for your location (reorder detection is based on frequencies and on/off times of the tones that vary by location). This will allow the application to hang up when the caller hangs up. The Set Reorder Tones step is set up for North America by default.

couldnt find Set Reorder step <br> <br>Im using Teleflos 2005.0.2.1056

Look in the Advanced tab on the Steps Toolbox. (The tab labelled Adv) <br> <br>The tab may be hidden. To show the Adv tab, go to Environment >> Options >> Click the "Provide access to Advanced Steps" check box.

I am having a similar problem to this and have tried to place this Set Recording Tone step but it does not help. <br> <br>PROBLEM: <br>Application is set to make a SQL statement to check for records that are tagged as available and need to play a message over an outgoing call. The result of the call (ie., hangup, busy, complete) will then be included in another SQL Statement to update the database so it is tagged to not go out again. <br> <br>Our problem is that if the caller hangs up during the call it updates the database and returns back to the beginning and locks up on the Place Call step. <br> <br>We then check our records and what happens is the call that hung up is marked as such but all other calls thereafter are marked unanswered. This would be ok if the call was really unanswered but it does not even ring in. Everything worked as planned in the simulation environment but is doing this in the live environment. <br> <br>I should probrably add that we do not use the Finish step because we have it loop back to the beginning without any time delay. If we have the application set to finish, it takes too long to restart. If there was a way to restart it in a second the application would work as planned. <br> <br>Here is a partial log of the event where it errored out: <br> <br>/10/31 10:10:42.398: Place call to 6144101943 <br> and wait for up to 6 rings <br>2005/10/31 10:10:42.398: Do not connect on CED <br>2005/10/31 10:10:42.398: Do not connect on SIT <br>2005/10/31 10:10:42.408: ERROR: Port not available on SCbus <br>2005/10/31 10:10:42.408: (106): Invalid Switching Handler Bus Mode <br>2005/10/31 10:10:42.408: Warning: port's switch status unchanged. <br>2005/10/31 10:11:35.484: Setting system variable '@CALLOUT_RESULT' to 'NOANSWER' <br>2005/10/31 10:11:35.484: Setting system variable '@CALLOUT_REASON' to 'TIMEOUT' <br>2005/10/31 10:11:35.524: Attempting ag_unlisten, lines[curLine].chdev = 0x1 <br>2005/10/31 10:11:35.524: ag_unlisten - failure <br>2005/10/31 10:11:35.534: dx_close <br>2005/10/31 10:11:35.534: ReleaseLine done. <br>2005/10/31 10:11:35.534: TIMEOUT <br>2005/10/31 10:11:35.534: [17] Set Local Variable <br>2005/10/31 10:11:35.534: Setting local variable '@RESULT' to 'unanswered' <br>2005/10/31 10:11:35.534: [43] Connect Point <br>2005/10/31 10:11:35.534: [33] SQL Statement <br>2005/10/31 10:11:35.534: Warning time threshold not specified, using default of 2000 ms <br>2005/10/31 10:11:35.534: WARNING: Handle 1 still open. Closing handle <br>2005/10/31 10:11:35.534: <----- BEGIN -----> <br> update tbloutgoing set txt_datesent = '2005/10/31 10:11:35', txt_result = 'unanswered' where txt_phone = 6144101943 and int_alertid = 1

The log above doesn't appear to have any errors in it, perhaps the "errors" you are describing happened after this. <br> <br>I am assuming you are in an Analog environment, and so I am answering with the assumption in mind. Two things you should always do between calls (so, in your hang up handling): <br> <br>1) Put a hang up step in place, just to be completely certain a hang up has occurred. <br>2) After the hang up, you will require a Wait step. The length you require will vary somewhat based on the phone lines (well, the phone lines and any equipment they are running through/from, such as a PBX), but 1 to 2 seconds for analog is typical. This is necessary to ensure that all calls after the first will actually get a dial tone. If you hang up and place a call to quickly, you won't be able to succcessfully place an outbound call, and I suspect this may be what is happening with all your calls after the first.

The error I was refering to was "Port not available on SCBus." Maybe that is not an error with the steps in the applicartion though. The 2 second wait after a hangup fixed the issue. <br> <br>Our phone environment is an Integrated T1 that brings in VoIP and converts it within a Cisco router to analog for our PBX, fax, and other equipment.

It isn't an error, although the log output makes it appear to be one. The card you have doesn't support switching on the SCbus, but some steps attempt to do some setup for the SCbus, and generate an error. You can ignore that message anywhere you see it, unless it causes an application error to occur. (which shouldn't happen)