External Db Implementation With Vg7

[Guest BlackBird]

Hi,

Currently I am defining MS SQL 2005 as the external source to initiate outbound calls, I went to the online help file and followed the steps to do this when using Voice Guide 7.0 ( http://www.voiceguide.com/vghelp/source/ht...rnal_config.htm ) While in my final implementation I plan to load the outbound call data directly into the callque table, for this test (as recommended by the VG online help) I am using the Outbound Loader to up load test phone numbers into the external db (MSSQL 2005) in order to verify that the connection string and insert methods work correctly.

 

The behavior I noticed is it that when I insert a test call via the Dial List loader, it successfully inserts the entry in the MS SQL server, but insert also occurs in the Vistadb in as well. With the above configuration, should the outbound call entry be made in the MS SQL server only? Am I missing a step or is the default behavior is to perform dual db (MSSQL and Vistadb) inserts?

 

Also, how do I validate that the db that is use to initiate the outbound calls is MSSQL and not the VistaDB?

 

As a reference my config.xml looks as follows:

 

<Dialer>

<OutDialQue_ADODB_Provider>System.Data.SqlClient</OutDialQue_ADODB_Provider>

<OutDialQue_Database>ASPNETDB</OutDialQue_Database>

<OutDialQue_ConnectString>Data Source=BLUEBOX\SQLEXPRESS;Database=ASPNETDB;User ID=sa;Password=XXXXXXXX;</OutDialQue_ConnectString>

<OutDialQue_SqlPrefix></OutDialQue_SqlPrefix>

<OutDialQue_SqlSuffix></OutDialQue_SqlSuffix>

<OutDialQue_PortToUse_LinkField>NONE</OutDialQue_PortToUse_LinkField>

</Dialer>

 

 

I attached the zip files containing the config.xml and the logs.

 

 

Regards,

-r

 

Config.zip

Log.zip

[SupportTeam]

VoiceGuide service and Dial List loader only connect to the database specified in the Config.xml <Dialer> section. Only one database connection is made so it is not possible for the system to insert into multiple databases.

 

Also, how do I validate that the db that is use to initiate the outbound calls is MSSQL and not the VistaDB?

If you have specified another database in the Config.xml <Dialer> section then you can just delete the VistaDB file from VoiceGuide's \data\ subdirectory (it's called vgDb.vdb3).

 

If you have specified another database in the Config.xml <Dialer> section then the VistaDB file will not be checked for or created on VoiceGuide restarts or Dial List loader restarts.

[SupportTeam]

Traces show that the reason why two of the calls were made twice was because they were manually hung up from the Line Status Monitor before they were answered. In those situations VoiceGuide will redial the number later on (regardless of what the redial counter is at), which is what is happening here.

 

Note that what the traces are also showing is that the Dialogic card reports there does not appear to be a working phone line attached to the Dialogic card - this is most likely the reason why you are not hearing the called number ring and then you press hangup on the Line Status Monitor. When a minute later you see the same call made again its the same call just being redialed.

 

Notice that when you give the line enough time to timeout by itself the entry in the database will be deleted (if retries run out) and no further calls are made.

 

 

In general analog lines are not a good choice for professional outbound systems. You should be using T1/E1 ISDN to get best results for outbound systems.

 

 

Relevant traces below.

 

 

 

142227.453 0 dial cmd_CallQue_Insert.ExecuteReader [787791 6831] sID=1, oID=1, iID=1

...

142227.453 dial Db_Insert_PortToUse id=1, guid=[c10440d5-630f-44e4-85de-f66341c95cac] sPortList=[1]

-----

142228.218 10 dial callque update id/guid=1/c10440d5-630f-44e4-85de-f66341c95cac nextActivateTime=10/30/2008 2:23:28 PM, retriesLeft=-2, iRelatedPortNumber=1 : completed ok

...

142228.234 10 1 state Dialing 7877916831

 

142228.796 6 1 ScriptEvent RLS_LCSENSE DX_OFFHOOK|CALL_OUTBOUND|ALERT Loop current not present. Working phone line not attached.

 

 

 

142235.031 0 dial cmd_CallQue_Insert.ExecuteReader [787791 6831] sID=2, oID=2, iID=2

...

142235.031 dial Db_Insert_PortToUse id=2, guid=[8a166dd0-1a0e-4a7a-9658-1f8dc2ae12f5] sPortList=[1]

 

 

142246.625 14 1 state Hanging up call... [LineStatusMonitorRequest]

 

 

142250.234 10 dial callque update id/guid=2/8a166dd0-1a0e-4a7a-9658-1f8dc2ae12f5 nextActivateTime=10/30/2008 2:23:50 PM, retriesLeft=-2, iRelatedPortNumber=1 : completed ok

...

142250.234 10 1 state Dialing 7877916831

 

142250.796 6 1 ScriptEvent RLS_LCSENSE DX_OFFHOOK|CALL_OUTBOUND|ALERT Loop current not present. Working phone line not attached.

 

 

 

142323.000 20 1 timer fired EV_TIMEOUT_MAKECALL_NORESPONSE

142323.015 10 dial Db_Delete_Entry begin id=2 guid=8a166dd0-1a0e-4a7a-9658-1f8dc2ae12f5

 

 

 

142328.265 10 dial callque update id/guid=1/c10440d5-630f-44e4-85de-f66341c95cac nextActivateTime=10/30/2008 2:24:28 PM, retriesLeft=-3, iRelatedPortNumber=1 : completed ok

...

142328.265 10 1 state Dialing 7877916831

 

142328.812 6 1 ScriptEvent RLS_LCSENSE DX_OFFHOOK|CALL_OUTBOUND|ALERT Loop current not present. Working phone line not attached.

 

 

142401.062 20 1 timer fired EV_TIMEOUT_MAKECALL_NORESPONSE

142401.062 10 dial Db_Delete_Entry begin id=1 guid=c10440d5-630f-44e4-85de-f66341c95cac

 

 

 

142557.921 0 dial cmd_CallQue_Insert.ExecuteReader [7874782634] sID=3, oID=3, iID=3

...

142557.921 dial Db_Insert_PortToUse id=3, guid=[3bd51f7f-7e40-4e30-9097-c7a60357b3dd] sPortList=[1]

-----

142558.265 10 dial callque update id/guid=3/3bd51f7f-7e40-4e30-9097-c7a60357b3dd nextActivateTime=10/30/2008 2:26:58 PM, retriesLeft=-2, iRelatedPortNumber=1 : completed ok

...

142558.265 10 1 state Dialing 7874782634

 

142558.812 6 1 ScriptEvent RLS_LCSENSE DX_OFFHOOK|CALL_OUTBOUND|ALERT Loop current not present. Working phone line not attached.

 

142606.281 14 1 state Hanging up call... [LineStatusMonitorRequest]

 

 

142658.265 10 dial callque update id/guid=3/3bd51f7f-7e40-4e30-9097-c7a60357b3dd nextActivateTime=10/30/2008 2:27:58 PM, retriesLeft=-3, iRelatedPortNumber=1 : completed ok

...

142658.265 10 1 state Dialing 7874782634

 

142658.828 6 1 ScriptEvent RLS_LCSENSE DX_OFFHOOK|CALL_OUTBOUND|ALERT Loop current not present. Working phone line not attached.

 

142731.062 4 1 timer fired EV_TIMEOUT_MAKECALL_NORESPONSE

142731.062 10 dial Db_Delete_Entry begin id=3 guid=3bd51f7f-7e40-4e30-9097-c7a60357b3dd

[Guest BlackBird]

My apologies, later I found out that at the moment I was conducting the test, the local telephone company was performing repairs/changes with our telephone lines. At the time of my post, my main concern then was with my perception that there was a the dual db entry issue (not an issue anymore) I did what you suggested on the previous post and deleted the VistaDB file and sure enough the VistaDB file was not created after VoiceGuide restarted.

 

VG worked like as you described it. I placed a few succesfull calls using the Dial List Loader and MSSQL. I liked the fact that the callque table clears immediately after the calls are executed, as well as the reports contained in the cdrout - perfect for my .aspx report page - so far VG7 rocks! kudos to your design team.

 

My next exercise is to load the call data directly into the callque table (without the Dial List Loader), I suspect that should go smoothly.

 

Thanks for your superb support!

 

 

[SupportTeam]

kudos to your design team.

...

Thanks for your superb support!

Thanks

 

My next exercise is to load the call data directly into the callque table

And the PortToUse table. Each CallQue entry must have 1 or more PortToUse entry - unless you explicitly turn off PortToUse in the Config.xml

 

 

[Guest BlackBird]

Yes, I explicitly turned off PortToUse in the Config.xml, the idea is to let VoiceGuide automatically assign the next available port as they become available.

 

Regards,

-r

[Guest BlackBird]

I hope you don't mind that I keep this thread alive, but I had one more step to inquire about, which has relevance to this thread.

 

As suggested by the online help file

 

It's recommended to use the Dial List Loader application to load some calls into the database and then examine the database tables to how the information is placed in the tables.

 

Via the Dial List Loader I am able to load calls into MSSQL server ASPNETDB : table Callque, the call is then executed - everything worked as expected.

 

At this point via a simple application I created, I am attempting to insert the outbound call parameters directly to the MS SQL Callque table. I am able to insert the outbound call data into MSSQL server ASPNETDB : table Callque, but the call is not executed at all, the entry sits in the table. I double checked that the data that I am inserting via my application match those inserted when using the Dial List Loader, the only exception are that the fields not being used, unused fields are set to NULL by my application. Here are my questions:

 

• When the PortToUse table is not in use, is the GUID use for anything else? What process generates the GUID? and should the GUID field be seeded and autoincremented (similar to the ID field which is seeded and autoincremented)?
• Once the dial list loader inserts the call into the MSSQL table, is there a transpatent process/procedure which is executed by the dial list loader in order to push the call? or rather, what causes the call to be executed once is inserted into the callque table?

 

 

Regards,

-r

 

[SupportTeam]

the only exception are that the fields not being used, unused fields are set to NULL

Which fields are left at NULL? Can you post a screenshot showing the entry loaded by DialListLaoder and and entry loaded your app?

 

When the PortToUse table is not in use, is the GUID use for anything else? What process generates the GUID? and should the GUID field be seeded and autoincremented (similar to the ID field which is seeded and autoincremented)?

The GUID field should be able to be left at null. You could of course try setting it to autoincrement as well and see if that makes any difference. It should not stop outgoing calls but may be an issue with deleting completed call entries - would need to check.

 

Once the dial list loader inserts the call into the MSSQL table, is there a transpatent process/procedure which is executed by the dial list loader in order to push the call?

No.

 

or rather, what causes the call to be executed once is inserted into the callque table?

VoiceGuide polls the database every second.

[Guest BlackBird]

Certainly, the attached zip file contains an xls file with entries inserted by both tools.

 

From the xls file, under the ID column #1 and #2 these are entries inserted by my tool.

From the xls file, under the ID column #5 represent a value inserted by the Dial List Loader.

 

DB_Values.zip

[SupportTeam]

Would need to run some tests to see if which of the fields being set to NULL instead of empty string results the entry no being dialed.

 

Do you maybe have vgEngine traces capturing what is happening on the system immediately after a new entry is inserted by your app?

 

Quickest fix would be to just insert empty strings in the columns that are currently not set, or change the table definition to have default values for those columns.

 

BTW. RetriesDelay is an Int field, so it should not have NULL in its column...

[Guest BlackBird]

Would need to run some tests to see if which of the fields being set to NULL instead of empty string results the entry no being dialed.

I did some test and noticed that while settings all of the unused fields where set to strings (RetriesDelay was set to 0), it did not seem to make a difference, no outbound call was placed. After a few trial combination, at the end, I left all of the unused fields set to an empty string instead of NULL, of course RetriesDelay (int) was set to 0 and the GUID field I left set to NULL, from a previous posting it seems that the GUID = NULL should not be a issue.

 

Do you maybe have vgEngine traces capturing what is happening on the system immediately after a new entry is inserted by your app?

No prob. The attached zip file contain the latest trace/logs. I also included an xls file which contains the new data sets inserted with my tool (row id 5#, 6#) and a new data set which was inserted by the Dial List Loader (row id #7 ) . For now The only field I left NULL is the GUID, although I did run some test earlier while setting the GUID field to a valid value, but no outbound call was made.

 

BTW. RetriesDelay is an Int field, so it should not have NULL in its column...

No prob., RetriesDelay is now set to int 0.

Log.zip

[SupportTeam]

The vgEngine trace attached shows that the VoiceGuide service is still looking in the PortToUse table for the calls. See all of the entries where the issued SQL is:

 

dial BuildSQL_FindNextCall_inPortToUse_Stage1: [sELECT TOP 1 PortToUse.CallID, PortToUse.CallGUID FROM PortToUse WHERE ( (PortTouse.ActivateTime <= @dateNow));]

 

This is probably because we see this in trace:

 

001918.593 5 db config bConfigXml_sDialer_OutDialQue_QueryPortToUseTable = true ()

 

We'll double check if turning off the PortToUse works properly in the version you have. We'll probably add some more debugging to this area of code so that we may better see what is happening.

 

 

 

 

[Guest BlackBird]

Then the following line in the config.xml is not being used, correct?

<OutDialQue_PortToUse_LinkField>NONE</OutDialQue_PortToUse_LinkField>

 

Since we are investigating the implementation of the PorToUse field, I like to contribute with a suggestion with regards to the PortToUse xml meta tag. Would it be possible to revert back to the earlier design used to define the telephone lines for outbound calling? By using the sLineSelection field, see http://www.voiceguide.com/vghelp/source/ht...iallistinto.htm

 

Lines should be specified as a comma delimited list of physical ports (eg: 1,2,3) or of the Dialogic line identifiers (eg: dxxxB1C2,dxxxB1C3). If any of the lines are allowed to to be used setting then this setting should be left blank. eg: 3,4,5 would indicate that the outgoing call can only be made on third, fourth or fifth port.

 

Imo, the earlier design is a far easier implementation since there is a dedicated db field ( sLineSelection ) used to control the specific lines to be used for outbound calls or to specify that all lines ( sLineSelection = blank) are open for outbound calling, rather than altering the xml tag or using two inserts commands. With the current VG7 design, even after reading the online help, it seems that the outbound phone line specificity and management is complex (just my humble opinion, ).

 

-r

 

 

[Guest BlackBird]

Hi team, just dropping at line to see if there has been any progress on this?

 

Also, I'm interested to hear if your design team would consider my suggestion to simplify the outbound line specificity and management, one of the many reasons I will be choosing VoiceGuide is for my final implementation is the ease to implement solutions with (at least with earlier versions), with that in mind I hope your design team would consider the suggested solution.

[SupportTeam]

QUOTE

Would it be possible to revert back to the earlier design used to define the telephone lines for outbound calling? By using the sLineSelection field,

That approach is no longer used as it was causing longer SQL query delays on large systems during call finding/selection. Inserting additional entries into the PortToUse table was judged to not add that much more complexity.

The sLineSelection field that is mentioned on the Help page you linked to is part of the OutDial file definition. The OutDial file format remains as before - but when loading the OutDial file VoiceGuide will store the port selections in the PortToUse table.

If you do not want to use PortToUse then you can disable VoiceGuide doing port limited selections by using:

<OutDialQue_PortToUse_LinkField>Disable</OutDialQue_PortToUse_LinkField>


The current latest version can be downloaded from: [old link removed] Please update to this version.

[Guest BlackBird]

Hi,

I downloaded the version provided via the link below. The naming convention leads me to believe that the fix you provided applies to MySQL, correct? I am using MS SQL 2005, assuming that the fix applies to MS SQL as well I installed the new VG version.

 

After the installation completed, I modified the newly installed config.xml with the proper connection string and added the suggested meta tag to disable the PortToUse table. Then I stopped the VG service, waited a few minutes and restarted the VG service in order to activate the new config.xml settings.

 

The result: I am able to load calls into MSSQL server DB:ASPNETDB , table:Callque, unfortunately, as initially reported the call is not executed at all, the entry sits in the CallQueue table. I attached the log files for you review, please advice.

 

Regards,

-r

 

 

 

Log.zip

[SupportTeam]

Trace shows that a valid ADO.NET data provider name is not specified. You currently have SQLNCLI specified. SQLNCLI is not a valid data provider name. For MS SQL the ADO.NET provider is System.Data.SqlClient

 

See the error at the bottom of this trace excerpt:

 

 

131357.890 5 0 ado.net factory classes installed on this system:

131357.890 5 0 System.Data.Odbc : Odbc Data Provider, .Net Framework Data Provider for Odbc, System.Data.Odbc.OdbcFactory, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089

131357.890 5 0 System.Data.OleDb : OleDb Data Provider, .Net Framework Data Provider for OleDb, System.Data.OleDb.OleDbFactory, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089

131357.890 5 0 System.Data.OracleClient : OracleClient Data Provider, .Net Framework Data Provider for Oracle, System.Data.OracleClient.OracleClientFactory, System.Data.OracleClient, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089

131357.890 5 0 System.Data.SqlClient : SqlClient Data Provider, .Net Framework Data Provider for SqlServer, System.Data.SqlClient.SqlClientFactory, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089

131357.890 5 0 VistaDB.NET20 : VistaDB Data Provider, .Net Framework Data Provider for VistaDB, VistaDB.Provider.VistaDBProviderFactory, VistaDB.NET20, Version=3.3.1.57, Culture=neutral, PublicKeyToken=dfc935afe2125461

131357.890 5 0 vgDb_ProviderInvariant Db_LoadConfig call

131357.890 5 0 config.xml read: /VoiceGuideConfig/Dialer

131357.890 5 db config OutDialQue_ADODB_Provider = SQLNCLI

131357.890 5 db config OutDialQue_Database = ASPNETDB

131357.890 5 db config OutDialQue_ConnectString = Data Source=BLUEBOX\SQLEXPRESS;Database=ASPNETDB;User ID=sa;Password=Coco11981997;

131357.890 5 db config OutDialQue_SqlPrefix =

131357.890 5 db config OutDialQue_SqlSuffix =

131357.890 5 db config OutDialQue_PortToUse_LinkField = Disable

131357.890 5 db config zConfigXml_sDialer_OutDialQue_PortToUse_LinkField = Disable (set in Config.xml)

131357.890 5 0 vgDb_ProviderInvariant Db_Open call

131357.906 5 0 Db_Open GetFactory call [sqlNCLI]

131357.906 5 ERROR v7.0.3236.32938 (Mon 10/11/2008 18:17:57.11) Db_Open GetFactory : Unable to find the requested .Net Framework Data Provider. It may not be installed.

[Guest BlackBird]

It is interesting to see that I am able to insert a record (row) with an invalid data provider (SQLNCLI). Good progress has been made, I went ahead and changed the ADO.NET provider to System.Data.SqlClient , the record is now inserted into the Callque table, and the call is initialized and placed, seems to working at least to that step.

 

While performing my verification, I noticed the following:

 

• On the Callque table the field RetriesLeft is set to 29, regardless on whether I leave the Retries Number to 3 or blanked. Should this field be set to the value I set rather than a defaulted value? this occurs whether I use my tool or VG's Outbound Call Loader to insert the entry. I also, noticed that disabling the PortToUse via the config.xml has an effect on the RetriedLeft value.

• When placing a call The status "Dialing 7874782634, Sending Fax Calling Tone..." I am placing an outbound call to a regular phone number (not a fax), Why is the system defaulting to "Sending Fax Calling Tone..."?

• VG does place the call, but, when I answer the call, the line remains silent, mute. The sound file specified in my simple test vgs script is not being played. Per the previous bullet, if VG is attempting to place a fax, is it possible that VG is waiting to get a fax tone, thus why the line is mute?

• When I hang up the telephone, the line status monitor shows that the call remains active. Should VG detect that I answered and hanged the phone, then release the line?

 

 

 

 

 

 

[SupportTeam]

Could you please stop VG and delete the tables in your Database, and delete all logs in VG's \log\ subdirectory.

 

Then start VG - VG will recreate the tables, and after VG has started then start the Outbouind Call Loader and load a single call into the system.

 

After the call is placed please .ZIP up and post all the traces that are in VG's \log\ subdirectory.

[Guest BlackBird]

I followed the steps outlined. Please see the attached log file.

 

regards,

-r

Log.zip

[SupportTeam]

Please stop VG and delete all the tables in the database (not jsust the CallQue and PortToUse tables). If not all tables are deleted then you will get errors like in your last trace:

051727.171 5 0 ERROR v7.0.3236.32938 (Mon 10/11/2008 18:17:57.11) Db_CreateTables_ExecuteNonQuery : There is already an object named 'VmMsgs' in the database.

After deleting all the tables please update to this version of VG: [old link removed]

This new version has just been tested here with MSSQL 2005 in setup where the PortToUse table is disabled (ie: <OutDialQue_PortToUse_LinkField>Disable</OutDialQue_PortToUse_LinkField> is used in Config.xml).

Please post traces as before if you still encounter problems. Please note that <OutDialQue_PortToUse_LinkField>Disable</OutDialQue_PortToUse_LinkField> must be used with this version.

[Guest BlackBird]

For this test round I performed the following:

• Uninstalled the existing VoiceGuide version
• Installed the new VoiceGuide version (per link)
• Stopped the VG service
• Modified the config.xml to add my connection string, the correct ADO provider and the PortToUse disable argument
• Deleted all logs
• Dropped all existing DB tables associated with VG
• Started the VG service
• Verified that the service created the pertinent tables in MS SQL
• Place a call via the Outbound call Loader, worked like a charm!
• Placed a successful the call via my application! the call got into the Callque table, and initialized the outbound automatically

 

Thank you so much for your diligence, for the excellent support and for providing a fix which should benefit MS SQL 2005 and MS SQL 2008 users!

 

Please consider this incident closed and the fix verified.

 

 

My next step is to deal with the TTS engine vendor, my TTS engine is having trouble sampling to 11kHz8BitMono, but that is a separate issue.

 

Thanks again for all the excellent, hard work!