Suppress TAPI Connection Line Busy Pop-ups

[tdubsley]

Hello All,

I'm working on a python script to simply connect to predefined sessions using TAPI. I noticed on some other older threads that there may have been functionality added to suppress pop-ups for connections that fail. Is there a way to automatically advance when there's some failure without having to select Ok in the dialog box? I tried adding the fail silently argument to the crt.Session.Connect method without any success. I'm currently using SecureCRT v7.3.1 and Python 3.

Thanks!!
Tom

[jdev]

Originally Posted by tdubsley

I'm working on a python script to simply connect to predefined sessions using TAPI. I noticed on some other older threads that there may have been functionality added to suppress pop-ups for connections that fail. Is there a way to automatically advance when there's some failure without having to select Ok in the dialog box? I tried adding the fail silently argument to the crt.Session.Connect method without any success.

When you use TAPI, you are instructing SecureCRT to turn over the dialing process to the Windows operating system's Telephony API (TAPI). Because, with TAPI, the Windows OS is the entity controlling the dial operation the Windows OS is the entity displaying dialog boxes during that dial process and returning control to SecureCRT only after the dial attempt has terminated. If you're using TAPI, there is no way in SecureCRT to tell the OS to suppress dialog popups during the dial operation.

If you want to consider an alternative to using TAPI, you can consider using a script to perform dial operations by using the Serial protocol to talk directly to the Modem. An example script is available here.

Originally Posted by tdubsley

I'm currently using SecureCRT v7.3.1 and Python 3.

SecureCRT version 7.3.1 has not been in active development since 26 Feb, 2015. It is strongly suggested that you upgrade to a version of SecureCRT that is current and in active development.

--Jake

[tdubsley]

Hi Jake!

Thanks for the response! I've upgraded one of our workstations to use 9.0 instead of v7. I've updated your script as a logon action and added the number to be dialed 1-XXX-XXX-XXXX. I've also updated the protocol to serial and switched over to COM15 which is where the modem is assigned. I'm getting an 'Init Sequence Failed' error when trying to connect to either of my predefined test sessions. I was able to switch back to TAPI and connect successfully. Any suggestions?

Thanks!!
--Tom

[jdev]

Originally Posted by tdubsley

I'm getting an 'Init Sequence Failed' error when trying to connect to either of my predefined test sessions. I was able to switch back to TAPI and connect successfully. Any suggestions?

The "Init Sequence Failed" error message is coming from this block within the script code:

    ' Send a generic modem init string: You may need
    ' to modify this to meet your specific needs.
    crt.Screen.Send "AT&A3&B1&D0&K0&M4&N3&U3&R1" & vbcr
    If Not crt.Screen.WaitForString("OK", 3) Then
        crt.Dialog.MessageBox _
            "Init sequence failed.", _
            g_strScriptTitle
        crt.Session.Disconnect
        Exit Sub
    End If

As indicated in the comments, "You may need to modify this to meet your specific needs". In other words, the init string that is being sent to your modem within the script code may not be generic enough for your specific model of modem.

You may want to turn on modem logging within Windows, dial with TAPI, and then take a look at the modem log file Windows wrote to and see what specific init string is being sent to the modem when Windows' TAPI is doing the dialing -- then you'll have an init string that you know would likely work for you when talking to the modem directly via its serial port.

How do you turn on modem logging in Windows? That's typically done within Windows (outside of SecureCRT entirely) - check your control panel's Phone and Modem settings, select the "Modems" tab, select your modem and press the "Properties" button; select the Diagnostics tab and you should see a "Logging" section that you can enable.

Once you find the modem init string that Windows is using when it talks to your modem, you'll tell the script to use that same init string by replacing the value within ""s below:

    crt.Screen.Send "AT&A3&B1&D0&K0&M4&N3&U3&R1" & vbcr

It's also possible that the init string is OK, but the modem is slow to reply with the expected OK (within 3 seconds).

    If Not crt.Screen.WaitForString("OK", 3) Then

Another approach you could take is to increase the timeout to, say, 5 seconds and see if you get a reply. If you're seeing evidence in SecureCRT's terminal window that the modem isn't accepting the init string (producing some error text, perhaps?), then clearly it's the appropriate init string you'll need to discover. Consult the manufacturer of your modem to find out what common init string values are supported and can be used, then adjust the script code to send only supported values.

Does that help explain where you need to go next?

[tdubsley]

Thanks for the quick reply! So I've removed that block to see if I can move forward and I'm getting a runtime error on line 99 where you have

cResponses = CreateObject("Scripting.Dictionary")

The error I'm getting is:

"Error: Wrong number of arguments or invalid property assignment: 'cResponses'"

Any feedback on what I can do to get past this error?
Thank you!
--Tom

[jdev]

Originally Posted by tdubsley

I'm getting a runtime error on line 99 where you have

cResponses = CreateObject("Scripting.Dictionary")

The error I'm getting is:

"Error: Wrong number of arguments or invalid property assignment: 'cResponses'"

Any feedback on what I can do to get past this error?

Looks like a typo in the script example. I'm sorry about that.

Try adding the keyword "Set" to the very beginning of that line, so it reads like this:

    nTimeout = 30
    Set cResponses = CreateObject("Scripting.Dictionary")
    cResponses.Add "1", "CONNECT"
    cResponses.Add "2", "BUSY"
    cResponses.Add "3", "NO DIAL TONE"
    cResponses.Add "4", "NO CARRIER"

Does that allow you to move forward?

--Jake

[tdubsley]

That was it! Thank you Jake!!

So my next question, since I'm using python to iterate through each one of my predefined sessions, I'm going to need to do some tweaking as I was only simply looking to see if the session was connected or not. However, I'm now running into an issue while I'm trying to test that I can't run a script because there is another script that is running.

Within the python script I think I'm going to simply be looking for the 'ogin:' (or something like that) string and then disconnect since I'm only looking to see if I can connect to the device or not. Every success or failure going to text file for logging.

What would you recommend as a path forward? Since I don't really know much about VBScript I was thinking maybe convert it to Python and just bake everything into the one script and just have that run without any additional logon scripts?

Thanks again for your help!
--Tom

[jdev]

If all you're doing is looking for "ogin:", then you already have a VBScript example that shows you how that is done with a WaitForString call to the Screen object.

Depending on what you want to accomplish, you may have better luck converting to a python script.

Either way you want to go, it's up to you to decide what will work best for your scenario.

My suggestion would be to *not* use a logon script if you're trying to iterate over a lot of sessions. The mere act of iterating with a script that you're already running disqualifies the idea of using a logon script. I'd suggest that now you know how to drive the dialing process via Serial, you can drive it just the same through python as you could through VBScript; drop the logon script and iterate with your python code over all your existing sessions, dial each number, look for "ogin:" or some other data suggesting success/fail and move on.

--Jake