Reference8:TAPI Service Provider

This is work in progress and describes yet unreleased software. For current planning, see Support:DVL-Roadmap TAPI V8

The innovaphone PBX V8.0 based TAPI Service Provider (TSP) is an enhanced version of the previous TSP version that takes advantage of the new SOAP features provided with version 8 PBX firmware.

The previous TSP still must be used for V7 PBX systems.

This article describes how to install and use it as well how to configure the PBX in order for the TSP to work properly.

Applies To

This information applies to

• innovaphone PBX V8.0 based TAPI Service Provider, Build 8001 and later
• innovaphone PBX V8 and later

More Information

Enhancements

Support for V8 firmware devices

Each user object device is represented as a TAPI line (all sharing an identical address, the objects extension a.k.a. Number property). This now allows to select individual registration devices when multiple devices are registered with the same PBX. Please note that in V8, mobility devices are not shown and thus not represented by TAPI line device. This was introduced in V9 only.

Support for presence based lines

These are TAPI lines shown which reflect the users presence state. Presence state open is mapped to a TAPI device status in service. Presence activity on-the-phone is mapped to a virtual call in state connected.

System Requirements

The TSP will install on any Windows 32bit and x64 platform down to Windows XP/Server 2003. For older systems, you must use a deprecated previous TSP version . For systems running PBX firmware version 6 or earlier, you must use the even older version 5 based TSP . Note that there is no x64 version of the version 5 TSP!

Download

The V8 TSP will be available on the apps section of the V8 download page.

Installation

Windows cannot run a Win32 TSP on an x64 platform (although it can run Win32 applications on such platforms). This is why there are 2 versions of the setup, the x64 installer (setup64-release.msi) and the Win32 installer (setup32-release.msi.

The release setup packages provided will install the retail version. This is recommended for production purposes but provides no debug options whatsoever. To track down possible problems, support may instruct you to install the debug version.

The TSP may be installed on each machine where a desired TAPI based application is to be run. If for example, Outlook is to be used, then each client PC running Outlook may have the TSP installed. Although this is typical for a 1st party configuration, all clients may have full 3rd party functionality, that is, they may control all existing lines.

As an alternative, the TSP can be installed on a single machine and a 3rd party TAPI server product (such as the IXI-Call Server available as a separate product) may be used to provide the network clients with a TAPI interface. Also, Microsoft’s Remote TAPI Server should work but is not being tested, so you use it on your own risk.

To install,

• select and download the setup32-release.msi install packages on 32bit platforms or the setup64-release.msi install package on 64bit platforms.
• double-click the install package to launch the installer

• accept the license agreement
• select the target folder
• complete the installer

When the installer has copied all files to the target machine, you need to add the TSP to the machine's TAPI system

• open the Telephone and Modem control panel
• Switch to the rightmost tab (Extras)
• Click on the Add... button

• Select the innovaphone TAPI provider driver
• Fill out the configuration dialogue
• Install the provider by clicking OK

File Organization

Windows forces all TAPI service provider files to reside in Windows' System Folder. This is the system32 folder in your windows install directory (usually C:\windows\system32), even if you are running an x64 platform! The installer will thus copy these files (tsp7-64.tsp and tsp7-64UI.dll) in to this directory. All other files however will be copied to the innovaphone AG\innovaphone® PBX V7-64-Win32 TSP or innovaphone AG\innovaphone® PBX V7-64-x642 TSP (depending on your platform) folder underneath your systems Program Files Folder.

The subdirectories Debug and Logs are created. Debug contains the driver's debug version, Logs will receive the log files when a debug version is used.

On x64 platform systems, the Win32 version of the configuration DLL (tsp7-64UI.dll) will be installed to the windows Windows on Windows64 System Folder (SysWOW64).

Switching back to the Retail Version

To go back from the debug to the release version, proceed as follows:

• close Telephony and Modem Control Panel if you have it open
• shut down windows telephony service. This can be done from the Windows Service Control Panel or by invoking net stop tapisrv from a command prompt
• delete the debug driver files from your system directory. On x64 systems, be sure to use a 64bit application such as Windows File Explorer for (explorer.exe) for this. Windows will silently redirect any 32bit application to the SysWOW64 directory when accessing system32
• repair the installation using windows Programs Control Panel or by invoking the original .msi again

There is no need to remove the driver from the Telephone and Modem Control Panel, as this would make you loose your driver configuration.

Please note that simply re-installing the driver from the original .msi without removing it from the system directory will not work.

Upgrading to a newer Version

When you attempt to upgrade the TSP from a previous version, the Windows installer will first remove any previous installation. When the new software is installed then, the TSP will be installed again into the TAPI system.

There is no need to remove the driver from the Telephone and Modem Control Panel, as this would make you loose your driver configuration.

Upgrading from the old Win32-only Version

If you upgrade from the older Win32-only versions of the TSP (soap-appl/tapi/7.00 or soap-appl/tapi/5.00), you must first remove the old TSP from telephone and modem control panel and uninstall the old product from the Software (or Programs and Functions) control panel.

When you upgrade from the old V7 64-bit TSP (soap-appl/tapi/7.00-64), you should first update this older version to the latest build available.

This procedure ensures that during the upgrade your TAPI lines retain their internal identifiers and thus their meaning in your TAPI application's configuration.

Uninstalling the TSP

To uninstall the TSP proceed as follows

• Remove the TAPI driver from the TAPI system using Telephony and Modem Control Panel
• close Telephony and Modem Control Panel
• shut down windows telephony service. This can be done from the Windows Service Control Panel or by invoking net stop tapisrv from a command prompt
• remove the installation using windows Programs Control Panel or by invoking the original .msi again

You will notice that Windows may fail to remove the driver files from the Windows System Directory. To clean up remove tsp7-64.tsp and tsp7-64UI.dll from the system32 folder as well as - on x64 systems - from the SysWOW64 folder.

Also, if you did run the debug driver, any remaining debug files in the Logs folder are left over and need to be removed manually.

Configuration

The TSP configuration dialogue looks like this:

• The VERIFY button will verify the configuration. Note that the Username drop down list will only be populated after a successful verify.
• The OK button will save the configuration.
• The CANCEL button will quit the configuration without saving any changes. If it is the initial configuration while you add the TSP via the telephone and modem control panel, the TSP will not be added

TAPI talks to the PBX using SOAP which in turn uses HTTP for communication. Both secure (https) and non-secure (http) communication is supported. In any case, HTTP basic authentication is used. To be able to connect to the PBX, the TSP needs to know proper credentials to use during HTTP authentication. These are referred to as PBX Account and PBX Password. Also, a suitable TAPI User must be selected.

Controlling the Line Devices handled by TAPI

TAPI connects to your PBX as a PBX user referred to as TAPI User. It will see all PBX objects that are members of groups in which the TAPI User is an active member. If the TAPI User is not an active member in any group, TAPI will see the TAPI User object only. This may be useful in a 1st party TAPI scenario. PBX objects are represented as TAPI lines.

The PBX object you use as TAPI User needs to have at least Groups/Call Forwards Only PBX user rights. Its Long Name property is used as TAPI User Username, its Name property as PBX Account and the password as PBX Password. This is why the PBX object used as TAPI User must have a password configured.

1st Party Configuration

In a 1st party scenario, the TSP will only work on a single PBX object. This will typically be a user's phone and thus the user itself will be used as the TAPI User.

In such a configuration the TSP is typically installed on the users PC and the CTI software is accessing TAPI directly (such as e.g. Microsoft Outlook does).

The TSP configuration dialogue will check for the number of lines seen. If it is only one, then it will issue a warning message:

This is because 3rd party configurations are much more common and this situation often indicates a configuration problem. In a first party configuration, you can safely ignore this message.

3rd Party Configuration

In a 3rd party configuration, the TSP will work with multiple PBX objects.

Typically, you will share a single TSP instance on a server system for use by several users on their desktop PCs. This is done by virtue of a TAPI Server. There are various TAPI server products available on the market, including but not limit to the [IXI Call product] marketed by innovaphone and the remote TAPI server included in Microsoft Windows server operating systems.

In this scenario, it is recommended to create a pseudo PBX user object for use as the TAPI User. This pseudo user is often called _TAPI_. You would create a dedicated group to control the list of PBX objects the TSP creates a line device for. This group is often called tapi.

Selective Call Forwards

Many CTI applications support distinct call forwards for internal and/or external calls. The TSP will translate such requests to a call forward on the PBX which has the Only or Only not property set to the number of the trunk line. For this to work, it needs to know this number. To know the number, the trunk line PBX object must be seen by the TSP (see above). If this is not the case, the TSP configuration dialogue will issue a warning:

In a vanilla first party scenario, this is obviously not the case. If you don't care, you can safely ignore this issue. Attempts to set such call forward will be rejected then as operation unavailable.

Multi Site Configuration

In a system with multiple PBXs, the TSP needs to connect to each of the individual PBXs.

In this case, you would specify your master PBX as PBX Master. There is no need to configure the complete PBX tree to the TSP as it is determined dynamically on runtime by analysing the PBX/Node objects in the master PBX and their registration status. If a registered PBX is found, this PBX is added to the list of active PBXs and a new connection is established. The PBX tree is built and maintained dynamically. A reconfiguration or restart of the TSP is not required on changes thus. For this to work

• the PBX/Node objects must be visible to the TSP.
• the PBX object used as TAPI User must exist in each PBX with same properties (including the password)

In a replicated scenario, you would create a TAPI user as recommended above and leave the PBX and Node properties empty . You can disable slave detection by checking Do not monitor slaves property in the TSP configuration dialogue.

TAPI maintains an address property per line device. This usually is the lines extension. In a multi site configuration, the address property will be set to the Number property of the node the respective PBX object is configured in, plus the Number property of the object itself. So if an object has Number 42 and lives in node 801, then its correspondence line device will have address 80142. By checking the Use pure node extensions property in the TSP configuration dialogue, you change the algorithm so that only the objects own Number is used (42 in our example).

Standby Configurations

In a system with standby PBX for the master PBX, you need to specify the PBX Standby IP address. This will be connected if the master is unavailable. Note that there is no need to explicitly configure slave-standby PBXs.

Working with multiple, unrelated PBXs

When working with multiple, unrelated PBXs (that is, PBXs that do not form a PBX tree as slaves and masters do), the TSP cannot derive the list of PBXs to track from the registration status. To support such a configuration, you will need to configure the extraneous master PBXs manually using regedit. Please note that using regedit may harm your system and may even cause inability to boot!

To find and edit the right registry entries, proceed as follows:

• open the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Telephony\innovaphone® PBX V7-64 TAPI Service Provider
• open its subkey Devicen where n is the provider id of the installed innovaphone TSP
• Open the FQDN key and add all extra PBXs
• For those PBXs that have a standby PBX, add a value to the StandbyFQDN key (please note: these are parallel lists. So master and standby need to have the same respective index in the FQDN and StandbyFQDN value lists)

The standard configuration UI will not show these extra values. However, it will also not touch them. So even if you use the standard UI to edit, only the first value in the lists will be changed and the remainder left unchanged. You can thus safely use the standard UI to edit all other values. As with multi site configurations, all PBXs need to be accessible using the same TAPI User.

Please note that this method is deprecated and will likely be removed from future versions of the TSP.

Setting the Line Device Name

The TSP will derive the line device's name from the properties of the respective PBX object. By default the name will be the objects Long Name followed by the name of the PBX the user ought to register with in parentheses. So if the users Long Name is Foo Bar and the registration PBX is branch1, the line device will be called Foo Bar (branch1). You can specify a different pattern by changing the TAPI Line Names property of the TSP configuration dialogue. The following replacement characters are available:

Meta	Replacement
%c	The objects Long Name (cn)
%C	The objects Long Name (cn) followed by the Name of the Device the line represents in braces [name] if it differs from the Long Name
%d	The objects Display Name (dn)
%D	The objects Display Name (dn) followed by the Name of the Device the line represents in braces [name] if it differs from the Display Name
%h	The objects Name (h323 alias)
%D	The objects Name (h323 alias) followed by the Name of the Device the line represents in braces [name] if it differs from the Name
%t	The Name of the Device the line represents
%e	The objects extension (e164)
%E	The objects extension (e164) prefixed with the objects node number
%N	The line address as reported to TAPI
%n	host name (of master pbx)
%p	:port-number (of master pbx's http access, empty if 80)
%P	raw port number of master pbx
%u	url-like user name (user@host)
%U	user url as per draft-levin-iptel-h323-url-scheme-04 (h323:://user@host:port)
%X	the PBX name the user is registered with (note that using this pattern may result in a change of the name when a standby situation occurs)
%x	the PBX name the user is reported by (note that using this pattern may result in a change of the name when the users PBX attribute changes)

The default pattern is %C (%x).

Trouble Shooting

Turning on Debugging

There are 2 versions of the TSP, debug and retail, which are both copied to the machine during setup. The retail version is installed into the system directories, whereas the debug version is stored in a separate directory. This is available through a short cut in the Start menu.

The TSP can produce a number of debugging messages which can be helpful to debug issues. By default, debug messages are written to the systems debug buffer mechanism (using OutputDebugString()). Such messages can be examined using standard debugging tools, such as for example dbgview which is available from Microsoft.

Debug messages have a class associated with it and the amount of messages written can be controlled by enabling or disabling specific classes. This is done by setting a bitmask in the registry value TraceLevel in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Telephony\innovaphone® PBX V8 TAPI Service Provider key.

The available classes include

Bit in TraceLevel	Class
0x00000001	Minimum tracing
0x00000002	TAPI api traces
0x00000020	Basic telephony object creation/destruction
0x00000040	Thread creation/destruction
0x00000080	Request creation/destruction
0x00000100	call related messages
0x00000200	Call id map
0x00000400	Warnings/Errors
0x00000800	Worker thread execution
0x00001000	Full lock/unlock notifications
0x00002000	Win32 Critical section create/destroy
0x00004000	Agent proxy support
0x00008000	constructor/destructor debug
0x00010000	development debugs
0x00100000	verbose debugging
0x00200000	SOAP trace
0x00400000	SOAP message dumps
0x01000000	ATL debug
0x02000000	line related messages
0x04000000	media related messages
0x10000000	dump call infos
0x20000000	dump PBX infos
0x80000000	output log messages to file

If TraceLevel is not set, it defaults to (hex) 00000400 in retail builds and to (hex) FFFFFFFF in debug builds. A nice value to use is (hex) 92200580. The TraceLevel can be changed during runtime of the provider (it may take up to 10 seconds though for the setting to take effect). In normal scenarios there is no need to install the debug version.

Saving Log Messages to a File

The 0x80000000 value is special, as it does not denote a message class. Instead, it turns on log file writing, both in retail and debug versions. For this to work, the registry value DoTraceFile must be set to 1 in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Telephony\innovaphone® PBX V8 TAPI Service Provider when the TSP starts. If this value is not present, it defaults to 1 in both retail and debug builds. Setting it to 0 disables log file writing regardless of any other setting. This may save some CPU cycles for installations with a real large number of lines.

The TSP will keep 24 log files (a days worth) by default. This value can be changed using the NumLogFiles value in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Telephony\innovaphone® PBX V8 TAPI Service Provider. Older log files will be removed. Also, when the TSP shuts down, the retail version will remove all log files it created so far. However, any TSP will only remove log files created by itself. This ensures that if the TSP or the system terminates prematurely, the log files will be kept even if a new instance is started and terminated later on.

Larger systems (500 monitored lines and more) can slow down considerably when using the debug drivers.

Installing the Debug Version

To install the debug version, you first install the retail version as outlined above. You then copy the debug driver files from the Debug directory to your windows system directory system32. You may want to use the shortcut to the Debug folder which has been installed to the start menu for convenience.

For the copy to work, proceed as follows

• close Telephony and Modem Control Panel if you have it open
• shut down windows telephony service. This can be done from the Windows Service Control Panel or by invoking net stop tapisrv from a command prompt
• copy the debug driver files to your system directory. On x64 systems, be sure to use a 64bit application such as Windows File Explorer for (explorer.exe) for this. Windows will silently redirect any 32bit application to the SysWOW64 directory when accessing system32

When you open Telephony and Modem Control Panel again, you should notice that the TSP driver name has changed to the debug version.

References

The test applications provided with this setup comes from Julmar Technology Inc.

Limitations

Please note that there currently is a limitation to 2000 users being in all active groups of a particular user. Thus, you cannot configure more than 2000 users to be handled by TAPI on a single PBX. This is a PBX limitation (and applies for all PBX groups).

TAPI has a flat line model. That is, all line numbers (aka extensions) are considered to live in a single name space. As a result, lines with identical numbers cannot be distinguished in TAPI (although they can exist). All extensions in all nodes of a PBX numbering tree are represented as TAPI lines. When the TSP works with a PXB that implements a hierarchical numbering tree, then some lines may receive identical numbers (their node-local extension which may overlap between nodes depending on the setting of the Use pure node extensions property). When a TAPI application uses these numbers to initiate calls to such lines, the call will work or not work depending on the calling lines position in the numbering tree (that is, lines within the same node as the called line will be fine, others may fail).

Known Problems

• The TSP is not tested with Microsoft’s Remote Tapi Server. While some installation have reported this to work fine, others have encountered problems. This scenario is not supported by innovaphone
• The TSP will read its configuration when it is loaded by the system. Thus, configuration changes require a re-load of the TSP. Unfortunately, there is no reliable way to force the system to unload the TSP, so you may have to reboot the system for changes to take effect. See the TAPI trouble shooting article for details
• The TSP will use HTTP basic authentication to talk the PBX. So if you disable basic authentication in the PBX's configuration, the TSP will not work. It is recommended to use HTTPS
• TAPI requires the TSP to assign a unique id to each line device. This ID must not change between re-boots of the system or between upgrades of the TSP. This is done by keeping a persistent table in the windows registry (in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Telephony\innovaphone® PBX V7-64 TAPI Service Provider\lineGUIDs) that maps the PBX's line GUID to a fixed integer value (known as permanent line id in TAPI speak). This key is retained even on uninstall. To get rid of it, you must remove it manually
• Microsoft installer fails to remove driver files installed to the windows system folder. This is why the TSP driver files are still present after an uninstall of the software. To get rid of them, remove TSP7-64.tsp and TSP7-64UI.dll from both %windir%\system32 and %windir%\sysWOW64

Tweaks

There are a few configuration options which should be used rarely. They can be enabled by setting an appropriate registry key.

There are some values in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Telephony\innovaphone® PBX V7-64 TAPI Service Provider:

ProcessorMask

REG_DWORD. If set, the TSP will use SetProcessAffinityMask(GetCurrentProcess(), set) to limit TSP execution to one or more of the existing processors. Set to 0xff by default.

There are some more values in a key underneath HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Telephony\innovaphone® PBX V7-64 TAPI Service Providercalled DeviceXX:

NoDuplicateConnectedCalls

REG_DWORD. If set to 1, the TSP will never show more than one call per line to be active. Extra active calls will be shown as on-hold. The situation occurs e.g. when a user initiates a 3PTY conference on the phone. This essentially is a bug fix for Microsoft's OCS client which forces any extra active call on-hold, thereby disturbing the 3PTY function. If your are using ESTOS' Call Control Gateway: from version 2.0.1.1474 - 05.11.2008 there is a fix for this same problem available. This option thus is deprecated.

List of supported TSPI functions

The TSP supports the following TAPI Service Provider Interface Functions. Note that these do not map one to one with TAPI user functions. For more information, see the Microsoft TAPI documentation.

TSPI_lineAnswer TSPI_lineBlindTransfer TSPI_lineClose TSPI_lineCloseCall TSPI_lineCompleteTransfer TSPI_lineDevSpecific TSPI_lineDevSpecificFeature TSPI_lineDial TSPI_lineDrop TSPI_lineForward TSPI_lineGenerateDigits TSPI_lineGetAddressCaps TSPI_lineGetAddressID TSPI_lineGetAddressStatus TSPI_lineGetCallAddressID TSPI_lineGetCallHubTracking TSPI_lineGetCallIDs TSPI_lineGetCallInfo TSPI_lineGetCallStatus TSPI_lineGetDevCaps TSPI_lineGetExtensionID TSPI_lineGetID TSPI_lineGetLineDevStatus TSPI_lineGetNumAddressIDs TSPI_lineHold TSPI_lineMakeCall TSPI_lineNegotiateExtVersion TSPI_lineNegotiateTSPIVersion TSPI_lineOpen TSPI_linePark TSPI_linePickup TSPI_lineRedirect TSPI_lineSelectExtVersion TSPI_lineSendUserUserInfo TSPI_lineSetAppSpecific TSPI_lineSetCallData TSPI_lineSetCallHubTracking TSPI_lineSetCallParams TSPI_lineSetCurrentLocation TSPI_lineSetDefaultMediaDetection TSPI_lineSetMediaMode TSPI_lineSetStatusMessages TSPI_lineSetupTransfer TSPI_lineSwapHold TSPI_lineUnhold TSPI_lineUnpark TSPI_providerConfig TSPI_providerCreateLineDevice TSPI_providerEnumDevices TSPI_providerGenericDialogData TSPI_providerInit TSPI_providerInstall TSPI_providerRemove TSPI_providerShutdown TSPI_providerUIIdentify

Notes on Consultation Calls

This TSP supports the lineSetupTransfer function. However, strictly speaking, this function is not needed and should not be used. It is merely intended for applications which do not offer a consultation call interface to the user when this function is not available. Instead, TSPI_lineMakeCall can be used where lineSetupTransfer would be otherwise. The notion of a special consultation call is an idiosyncrasy forced be legacy PBX technologies which were not able to transfer two arbitrary calls. In these scenarios, a potentially to-be-transferred call needed to be linked to the primary call. The PBX can transfer two arbitrary calls and thus there is no need for lineSetupTransfer. This ability is indicated by the LINEADDRCAPFLAGS_TRANSFERMAKE and LINEADDRCAPFLAGS_CONFERENCEMAKE flags. The transfer is then requested by using TSPI_lineCompleteTransfer.

Notes on 3PTY Conferences

The TSP supports the management of 3PTY conferences. These can be initiated by using TSPI_lineCompleteTransfer with LINETRANSFERMODE_CONFERENCE instead of LINETRANSFERMODE_TRANSFER. This is indicated by the flags LINEADDRCAPFLAGS_CONFERENCEHELD and LINEADDRCAPFLAGS_CONFERENCEMAKE. The 3PTY function is actually implemented by the innovaphone IP phones (such as IP2xx). Therefore, these capabilities are only advertised if the line is based on a PBX user object. Still, some lines where the capabilities are advertised cannot do 3PTY (such as e.g. DECT lines, analogue lines, 3rd party devices, ...). So the call to TSPI_lineCompleteTransfer will succeed but the conference will not be initiated and the subsequent call states will not indicate a conference (as there is no).

A 3PTY conference will create a new call handle for the conference. The only operation available for such a handle is TSPI_lineDrop. This will terminate the conference and restore the state active before the conference was initiated (that is, the phone that implemented the conference will now have 2 calls, one active and one on hold). This is indicated by not setting LINEADDRCAPFLAGS_CONFDROP.

Notes on parked Calls

The PBX can park calls from and to any existing PBX object, e.g. by virtue of specific feature keys. They are parked to/from a numeric park position. In SOAP however, calls are parked to an object by providing the objects UserInitialize() handle and a park position. Parked calls are then reported as straight calls with a distinct signalling state (8). The park position is not conveyed as part of the CallInfo record. To unpark, UserPickup can be used providing the parked calls call handle as call argument.

The TAPI specification is unclear on how the address information required to lineUnpark() a call can be obtained by an application (except that it is returned from linePark() if the call was parked using TAPI). The TSP thus indicates parked calls on a line with a call reason LINECALLREASON_PARKED. The caller id information is set to the parked calls call handle. This way, the application can take the caller id information and provide it to lineUnpark() to unpark a call. If the appication does not support this mode of operation but supports lineUnpark() and lets the user input the pakr identifier, the user can just provide the caller id information.

Some applications do not care for parked calls (by examining the call reason) and just blindly report these calls like ordinary connected calls (thereby confusing the user). To work around this problem, reporting parked calls can be turned off in the TSP configuration dialogue.

Notes on sending User to User Information

The TAPI specification for sending UserUserInfo closely resembles the way ISDN defines this service. Although the innovaphone PBX supports this service both with H.323 and SIP, it is not supported in this TSP. Instead, sending user to user information is implemented using H.323/SIP messaging. However, there are some important deviations and limitations caused hereby:

• data is not transparent. That is, the TSP only allows for null-terminated unicode to be sent. The data must be of even length and the last two bytes must be null.
• data is not sent within the call, but by initiating a separate call. This implies that the target number used to send the message carrying the data to is 'guessed' from the available call data. For example, if the call is in a connected state and a connected number is known, the message is sent to the connected number. If the call is in the ringback state, then either the called number or - if available - the redirection number is used and so forth.
• message calls are not indicated by the SOAP CallInfo records. As a result, messages (that is, user to user information) cannot be received with TAPI and lineReleaseUserUserInfo is not supported

Related Articles

Howto:Troubleshooting the TAPI service provider