innovaphone wiki - User contributions [en]

Howto:Projectcode / Pincode

2011-12-14T08:51:28Z

Okoenigs: /* innovaphone Configuration */

==Applies To==
This information applies to

* all innovaphone PBX´s v7 and later



{{FIXME|reason=has to be finished}}
==More Information==
This article describes how to configure a projectcode/pincode solution together with billing/accounting application (Samwin CAS).
If a project code is need to getting trunk access or for charging calls for a special project. Also for separating private calls and business calls with a pin and charging them separately.

===Problem Details===
If every user (> 100 users) needs an own private pin then this solution is not suitable, as the pins must be configured in the gateway aka "relay".
===System Requirements===
If also a report should be generated like on call amount then Samwin CBC must be used for billing/accounting purpose.

===innovaphone Configuration===
For using the pin you first dial into a waiting queue and then enter the pin. In the waiting queue there are DTMF destinations configured, so in this case you dial 8402 (for the WQ. Then you hear the waiting queue announcement (could be please enter your project or private pin). Enter your pin, e.g 2222 and the destination number including the trunk line access( e.g 00049703173009).

[[image:Projectcalls.png]]

Now as 2222 is dialed the DTMF destination 2 rules and 8722222 is called. The gateway object matches as it has 872 as number.

Via a gateway object the calls are routed into the relay.

[[Image:Pincode Project 2.png]]

In the relay the 872 is mapped and then the pin codes (e.g 2222) is stripped and the call is routed back into the PBX and out via your trunk line.

[[Image:Pincode Pin 3.jpg ]]

===Samwin CBC Configuration===

To differentiate private calls/project calls from "normal" calls , you need to configure a bundle. Like in that picture bundle 007* is gateway 7 in the innovaphone gateway, as bundle 001* is the gateway 1 in the innovaphone gateway.

[[Image:Pincode Samwin private.png]]

Samwin is recognizing his call as a private/project call and thus doing call reports also based on Pin code.

[[Image:Pincode_Samwin_private_1.png]]

The gateway CDR´s are used, Samwin is using the src_cdpn for recognizing the pin.

?event=B:Rel&time=1291128321&date=20101130-144521&ref=80dc8462e909d31188290090330617ef&dir=out&src_if=GW7&dst_if=GW7&src_cgpn=100&src_cdpn=87222220555&src_name=Nemo&dst_cgpn=100&dst_cdpn=0555&src_reg_name=Privat&bcaps=03_80_90_a3&xcoder=-,0(0,0,0)&rcoder=-,0(0,0,0)&xstats=0+0+0+0+0&rstats=0+0+0+0+0&alert_time=1291128319&disc_time=1291128321&srv_id=00-90-33-06-17-ef

== Related Articles ==

[http://www.innovaphone.com/index.php?id=140&L=0 | Samwin CBC]

[[Category:Howto|{{PAGENAME}}]]

Reference9:PBX/Objects/Edit Profiles

2011-12-06T14:08:40Z

Okoenigs: /* Properties of a Profile */

You can set various profiles per user, for each profile you can have a [[Reference9:Concept_myPBX#Contacts |buddy list (aka contacts)]] in the myPBX client.

'''Name''' Name of the profile, the myPBX user can choose from profile names if more are configured.

== Properties of a Profile==

{|
|valign=top nowrap=true|'''Name'''
|Name of the user that shows up in the buddy list
|-
|valign=top nowrap=true|'''No'''
|Number of that user that shows up in the buddy list
|
|-
|valign=top nowrap=true|'''Display'''
|How the user should be named in the buddy list
|
|-
|valign=top nowrap=true|'''Extern'''
|If its not an user from the PBX choose '''tel''' for a external phone number, or '''sip''' for an external sip user via federation
|
|-
|valign=top nowrap=true|'''Presence'''
|If you want to monitor the users presence state (that is only for external users), for internal you see the presence state if you have the [[Reference9:PBX/Objects/Edit_Allow |access rights]], used for federation
|-
|valign=top nowrap=true|'''Dialog'''
|If you want to monitor the users call state (that is only for external users), for internal you see the call state if you have the [[Reference9:PBX/Objects/Edit_Allow |access rights]], used for federation
|-
|}

* Note: For internal users configure either name or number.

Howto:Blue's Professional - Telcen - 3rd Party Product

2010-06-25T09:51:58Z

Okoenigs: /* Functions */

==Product name==
[http://www.imagicle.com/Products/BluesAccountingBilling/BluesProfessional/tabid/195/language/en-US/Default.aspx Telcen Blue’s Professional]

==Certification Status==

{{Template:Compat Status "certified"|certificate=Blue%27s_Professional_-_Telcen_-_3rd_Party_Product_-_Desc-telcen-cert.pdf}}

Testing of this product has been finalized February 16th, 2006.

==Category==

{{Category:RecProd Billing System / Call Management}}
[[Category:RecProd|{{PAGENAME}}]]
[[Category:RecProd Billing System / Call Management|{{PAGENAME}}]]

==Functions==
Call Management, Tarifmanagement

==Version==
Version 6.0.0.2 (driver Rel. 2)

==Vendor==
[http://www.telcen.it Telcen SpA]

==Description==
Blue's Professional is the most advanced Call Management software that allow to you to manage outgoing and incoming telephone traffic in unbelievable simply way. "Information only when you need it" is the guideline of this application that helps you to analize and easy decide: call accounting, telecom carrier choice, quality of service... Blue's Professional supports all PABXs connected via serial port RS232 or via TCP/IP, and it can manage large databases with remote sites and hundreds of extensions.You will return on investment in few months!

Blue's Enterprise Pro (SQL) is the version dedicated lo larger enterprises. It includes all the features of Blue's Professional and it provides you the best performance in managing million of calls database using the Microsoft SQL database (licence not included). You can manage remote sites and up to unlimited number of extensions depending only on the server that you will use. If you're thinking to definitely upgrade the way you manage your enterprise communications, Blue's Enterprise SQL is your choice.

==Pricing==
785 €uro - 48 extensions

==Contact==

{|
| colspan=99 | sales
|-
| Tel: || +39 0584 94 32 32
|-
| Mail: || [mailto:sales@telcen.it sales@telcen.it]
|-
| Internet: || http://www.telcen.it/de/index.asp
|}

[[Category:Compat|{{PAGENAME}}]]

Reference:Update Server

2009-10-14T09:36:23Z

Okoenigs:

== Configuration of the Update-Server ==
It is possible to update the firmware and configuration of a large number of innovaphone devices in a distributed environment by automated means.

This is done by storing the configuration and firmware information on a standard Web server, which in turn is called up the individual devices.

There are two modules in the device which work in tandem. The first is known as "UP0" and acutally executes the upload and download of configuration information as well as the download of updated firmware. UP0 is controlled by commands as detailed below.
The second module is known as "UP1". It serves to poll a given website for changed configuration information. If certain conditions are met, UP1 will issue commands to UP0 to perform the requested updates.

=== System requirements ===
* One or more Web server(s) accessible by the devices.
* The Web servers tested were MS IIS and the Apache server. It should, however, also work with all other common Web servers.
* For best results, the Web server should be able to manage a large number of simultaneous HTTP sessions. MS Personal Web Server, for example, is not a suitable Web server, since it manages a maximum of 10 simultaneous HTTP sessions.

=== Installation ===
To be able to transfer device configurations onto the Webserver, the latter must allow HTTP PUT requests. All other functions require HTTP GET authorisation.

Since all HTTP requests are executed unauthenticated, the Web server must allow anonymous reading and possibly also anonymous writing.

To allow HTTP PUT commands on a MS IIS, the read and write check box must be enabled in the configuration of the relevant virtual directory.

=== Configuration ===
Detailed information on how the URL parameter of the update server is configured on the innovaphone devices may be found in the chapter entitled "[[Reference:Configuration/General/Update|Configuration/General/Update]]".

Note here that the URL parameter must point precisely to the location of the file with the contained maintenance commands. It is also to be noted that this URL (just like all other URLs used by innovaphone devices) does not support host names. Therefore, a valid IP address always has to specified.

If the URL happens to end with a ‘/’, then a standard file name based on the product description is used. If, for example, the URL is <nowiki>http://1.2.3.4/configs/</nowiki> , then it is extended in the case of an IP1200 as follows: <nowiki>http://1.2.3.4/configs/update-ip1200.htm</nowiki> . The product name is specified in the first line in chapter "[[Reference:Configuration/General/Info|Configuration/General/Info]]". The file extension is irrelevant here. The extension *.txt or *.htm or no file extension at all is possible. In relation to URL specifications, note that some Web servers differentiate between upper case and lower case letters.

=== Running maintenance ===
The update file is immediately read and also immediately executed. After a device restart, the update server is automatically queried periodically in accordance with the interval set.

When the maintenance file has been successfully received, it is executed sequentially. Theoretically, all commands that can be transmitted to the device in a Telnet session or that occur in a configuration file can be used in the maintenance file.

=== Maintenance commands ===
Additional commands implemented specially for the update server are available.
The maintenance file is executed every time (depending on the interval set), as soon as it is received.

==== Check command ====
In most cases, however, the maintenance file should not be executed every time when it is received, but once only. Assuming that a certain configuration has to be loaded onto several devices, then it is best if this is done from a common source. This can be achieved with the check command:

mod cmd UP1 check <final-command> <serial>

innovaphone devices have an internal variable that is initially empty (or empty if the device was reset to the factory defaults) called UPDATE/CHECK. The check command compares the content of <serial> with the UPDATE/CHECK variable. If both match, all further commands of the maintenance file are skipped.

If they differ, the remaining commands are executed. When the last command has been executed, the UPDATE/CHECK variable is set to the value <serial>, and the <final-command> is executed. The following commands can be specified as <final-command>
* ireset: Resets the device as soon as it is not being actively used.
* reset: Resets the device immediately.
* iresetn: Resets the device as soon as it is not being actively used and a reset is required.
* resetn: Resets the device immediately if a reset is required.
* ser: no-op

==== Times command ====

Often, configuration changes shall be made only during certain times (e.g. non-working hours). This can be achieved using the times command:

mod cmd UP1 times [/allow <hours>] [/initial <minutes>]

The times command will check the current time against <hours>. If it does not match this restriction, any further processing of the command file is cancelled. <hours> is a comma separated list of hours. Only those hours listed are considered valid times for execution of the command file.

mod cmd UP1 times /allow 12,22,23,0,1,2,3,4

will allow command executions only between 12:00 and 12:59 and 23:00 and 4:59 local time (on a 24h clock). Note that if the device has no time set (yet), all command executions will be cancelled.

If the /initial parameter is set, then no commands will be executed within the first <minutes> minutes after the device has been booted. This is done to avoid firmware download and flashing when installing devices.

mod cmd UP1 times /allow 12,22,23,0,1,2,3,4 /initial 6

will suppress any command file processing within the first six minutes after each boot of the device. If /initial is set, for new devices (or those that have been reset to factory settings), the command file will be retrieved even if it normally would be suppressed by the /allow parameter. This allows new devices to retrieve a site specific standard configuration quickly.

==== Prot command ====
To initiate a firmware update, the following command can be executed:

mod cmd UP0 prot <url> <final-command> <build-serial>

This command downloads new firmware (if available) from the specified URL onto the device. Finally, the <final-command> is executed.
innovaphone devices have an internal variable that is initially empty (or empty if the device was reset with the standard settings) called UPDATE/PROT. The prot command compares the content of <build-serial> with the UPDATE/PROT variable. If both match, no firmware is downloaded. If the UPDATE/PROT variable is not set (new devices or after a device restart), the content of <build-serial> is compared with the built number of the current firmware. Once the firmware has been successfully downloaded, the UPDATE/PROT variable is overwritten with the content of <build-serial> . Note that the <build-serial> parameter is not compared with the firmware version currently loaded. It is the responsibility of the administrator to keep this standard.

If the <url> parameter ends with a slash (‘/’), a standard firmware file name is appended to the URL depending on the product description (for example, IP1200.bin for an IP DECT system).

mod cmd UP0 prot <nowiki>http://192.168.0.10/firm/ip1200.bin</nowiki> ireset 04-5656

The command<br>
mod cmd UP0 prot <nowiki>http://192.168.0.10/firm/</nowiki> ireset 04-5656

determines whether the firmware version 04-5656 was already installed. If this is not the case, the current firmware is downloaded from the address 192.168.0.10/firm/ip1200.bin, the UPDATE/PROT internal variable is overwritten with 04-5656 and, finally, the device is reset as soon at it is not being actively used.

==== Boot command ====
With the boot command, the boot code is updated and this is done in the same way as with the prot command.

mod cmd UP0 boot <url> <final-command> <built-serial>

The command<br>
mod cmd UP0 boot <nowiki>http://192.168.0.10/firm/</nowiki> ireset 205

determines whether the boot code version 205 was already installed. If this is not the case, the current boot code is downloaded from the address 192.168.0.10/firm/boot1200.bin, the UPDATE/BOOT internal variable is overwritten with the version number of the downloaded boot code (205) and, finally, the device is reset as soon as it is not being actively used.

Since V6.00 sr2-hotfix3 the commands "reboot" and "ireboot" are available and should be used to reset the device after boot code update to activate it. The system is run down the same way as with "reset" and "ireset" but finally a watchdog restart is forced instead of a soft restart.
Note that this command doesn't work with IP21!

==== Bmc command (only for DECT devices)====
With the bmc command, the DECT radio code ( aka burst mode controller firmware or BMC code ) is updated and this is done in the same way as with the prot command.

mod cmd UP0 bmc <url> <final-command> <build-serial>

The name of the file to use must be given explicitely here (the file name appended to an <url> parameter ending with a slash (‘/’) has no ".bin" suffix like the delivered file).<br>
The command<br>
mod cmd UP0 bmc <nowiki>http://192.168.0.10/firm/ccfp1200.bin</nowiki> ireset PCS04fd

determines whether the DECT radio code PCS04fd was already installed. If this is not the case, the current DECT radio code is downloaded from the address 192.168.0.10/firm/ccfp1200.bin, the UPDATE/BMC internal variable is overwritten with PCS04fd and, finally, the device is reset as soon at it is not being actively used.

==== SCFG command ====

mod cmd UP0 scfg ''<url>'' [''<final-command>'' ''<save-serial>'' [ /force ''<hours>'' ]]

This will cause the device to upload its current configuration to ''<url>''. This will be done using an HTTP PUT command. ''<url>'' must be writable thus. Within ''<url>'', some meta character strings are replaced as follows:

{|
! style="background-color:#DCDCDC;"| Sequence !! style="background-color:#DCDCDC;"| Replaces !! style="background-color:#DCDCDC;"| Example
|-
| #F || kernel build number || 08-12345
|-
| #B || boot code build number || 401
|-
| #H || hardware build || 102
|-
| #h || Device hardware number || IP1200-03-0d-f0
|-
| #m || MAC address of the device || 00-90-33-03-0d-f0
|-
| #d || Current date and time || 20051010-170130
|-
| #b''n'' || rolling backup index || 3
|-
| #i || (one of) the local ip-address(es) || 192.168.0.1
|}

This meta character strings are available in the URL of SCFG command and in the Update Server URL only.

The rolling backup index loops over 0 .. ''n''-1 for each backup and can only be used once in an update script. That means more than one SCFG command in a script with a usage of the rolling backup index will overlap and produce unexpected results.

Beginning with V7.00 the optional Parameters ''<final-command>'', ''<save-serial>'' and '''/force''' ''<hours>'' will be recognized.
* ''<final-command>'' defines the command to be executed after successful completion of scfg (typically '''no-op''' is used).
* ''<save-serial>'' is compared to the UPDATE/SCFG variable. If it is not equal, the command is started. If it is equal and '''/force''' is not specified the command is skipped, otherwise '''/force''' is evaluated.
* /force ''<hours>'' specifies the number of hours after which '''scfg''' is executed again even if ''<save-serial>'' has not changed.

mod cmd UP0 scfg <nowiki>http://192.168.0.10/configs/saved/#h#b5.txt</nowiki> no-op WEEKLY /force 168

will save the device configuration once per week with a backlog of 5 weeks.

==== CFG command ====
A configuration file may be loaded using the CFG command:

mod cmd UP0 cfg <url> <final-command> <serial>

The file will be read, all configuration commands in there executed and a final '''config write''' appended. Please note that no activation will be done implicitly. Thus, you will likely either use '''reset''' as <final-command> or use '''ser''' and have a '''config activate''' and '''iresetn''' follow.

=== Special WiFi (WLAN) IP72 commands ===

IP72 terminals are operated in different power-save modes, in order to enable longer battery life and reduce charging periods. However, these power-save modes are optimized for VoIP applications and perform rather poorly in a bulk firmware upload scenario. Broken http sessions and hanging and not correctly functioning updates may result.

The solution for the problem is to temporarily deactivate the configured power-save mode until the firmware upload completes.

This is done automatically for the web-based firmware and bootcode upload, but has to be '''explicitly''' stated in an update script.

Command to explicitly set active-mode (deactivate power-save):
mod cmd WLANMGR0 activate-pwr

Upon firmware (and bootcode) upload completion, power-save should be enabled again by:
mod cmd WLANMGR0 deactivate-pwr

So here an example:

...
mod cmd WLANMGR0 activate-pwr
mod cmd UP0 prot http://192.168.0.10/firm/ ireset 04-5656
mod cmd WLANMGR0 deactivate-pwr
...

If firmware upload has been initiated, the terminal is resetted and the deactivate part is not being invoked, this is, however not a problem, because after reboot, the terminal starts in a preconfigured power-save mode anyhow.

A reference to other WLAN commands: [[Howto:Firmware Upgrade and initial Configuration of IP72 via USB#Other_useful_commands]]

=== Example ===
A Web server exists at the address 192.168.0.10 with a subdirectory called configs. In this directory, there are two further subdirectories, in which the current firmware files for all innovaphone devices are stored.
Clients provide the DHCP server with the option #215 as <nowiki>http://192.168.0.10/configs/</nowiki>. In this directory, there is a file update-ip1200.htm , which processes the following lines:

mod cmd UP1 times /allow 23,0,1,2,3,4 /initial 6
mod cmd UP0 scfg <nowiki>http://192.168.0.10/configs/saved/#h.txt no-op WEEKLY /force 168 </nowiki>
mod cmd UP0 prot <nowiki>http://192.168.0.10/configs/04-5679/</nowiki> ireset 04-5679

This example demonstrates how the configuration of a device is stored on a Web server; all IP1200 devices are then instructed to load/update the firware version 04-5679 in the time period 23:00 hrs to 04:59 hrs. New devices are updated after a restart and after the specified six minutes have elapsed.

There is also the file update-ip3000.htm, which reads the following two lines:
mod cmd UP1 times /allow 23,0,1,2,3,4
mod cmd UP0 prot <nowiki>http://192.168.0.10/configs/04-5679</nowiki> /ser 04-5679

IP3000 devices are updated to firmware version 04-5679 in the time period 23:00 hrs to 04:59 hrs.

====Using an innovaphone box as web server====
Any box with a CF slot and a CF card installed can serve as web server platform to read update scripts, firmware files, configuration files or to save configurations from V6 SR1 on.

====Synchronous operation====
All commands issued by UP1 to UP0 (prot, boot, bmc, cfg and scfg) and all other commands (config...) run synchronous, i.e. UP1 wait's for the result of a command before starting the next one.

====Manual Update====
An manual update can be forced by the following command:

mod cmd UP1 poll



== Common Problems ==
The [[Reference7:Configuration/General/Update|Reference:Configuration/General/Update]] tab will show the update client status. Common error message include:

* not polled. The client has not (yet) polled the command script. This is probably because the script is polled the first time only ''after'' the interval has expired
* failed(401). The client has no sufficient access right to read the command script from the HTTP server
* failed(404). The update command script does not exist. You probably misspelled the path or name.
* failed(502). Might indicate problems with a proxy server on the far end. However, the HTTP client currently generates 502 for badly formed URLs also (e.g. <code>http:172.31.2.3/drive/cf0/update/update-all.txt</code>)

Generally, numeric error codes in parantheses (such as <code>failed(401)</code>) are taken from the last HTTP error code received by the update client. More about HTTP error codes can be found in the [http://de.wikipedia.org/wiki/HTTP-Statuscode German] and [http://en.wikipedia.org/wiki/List_of_HTTP_status_codes English] wikipedia .

Reference:Configuration/ETH/DHCP-Server

2009-08-26T16:18:43Z

Okoenigs: /* Offer Parameters: */

If the DHCP server was enabled (see chapter entitled "[[Reference:Configuration/ETH/DHCP|Configuration/ETH0-1/DHCP]]"), it can be configured here.

All settings marked with a "'''*'''" are innovaphone-specific settings that may only be found with innovaphone devices.

{|
|valign=top nowrap=true|'''Lease Time [min]:'''
| The validity period of the DHCP lease in minutes.
|-
|valign=top nowrap=true|'''Check Interval [min]:'''
| The interval (in minutes), at which a check is made whether the DHCP lease is still valid.
|}

== Address Ranges: ==
{|
|valign=top nowrap=true|'''First Address:'''
| The IP-Adresse that represents the start of the address range (for example, 192.168.1.100).
|-
|valign=top nowrap=true|'''Last Address:'''
| The IP-Adresse that represents the end of the address range (for example, 192.168.1.110).
|}

== Offer Parameters: ==
{|
|valign=top nowrap=true|'''Network Mask:'''
| The network mask in respect of the IP-Adress (for example, 192.168.1.100 corresponds to the network mask 255.255.255.0).
|-
|valign=top nowrap=true|'''Default Gateway:'''
| Standard router address (for example, 192.168.1.1).
|-
|valign=top nowrap=true|'''TOS Priority:'''
| ToS (Type of Service) value for voice packets (0x10).
|-
|valign=top nowrap=true|'''IP Routing:'''
| List of static IP-Routes in form of comma separated ''Address:Mask:Gateway'' triples (for example, 192.168.20.0:255.255.255.0:192.168.1.2,192.168.30.0:255.255.255.0:192.168.1.3).
|-
|valign=top nowrap=true|'''DNS Server 1:'''
| Primary DNS server address.
|-
|valign=top nowrap=true|'''DNS Server 2:'''
| Secondary DNS server address.
|-
|valign=top nowrap=true|'''Domain Name:'''
| Domain name that client should use when resolving hostnames via DNS (aka primary DNS prefix).
|-
|valign=top nowrap=true|'''Syslog Server:'''
| Syslog server address.
|-
|valign=top nowrap=true|'''Time Server:'''
| Time server address.
|-
|valign=top nowrap=true|'''Timezone String *:'''
| Time zone setting according to the IEEE POSIX standard (for example, CET-1CEST-2,M3.5.0/2,M10.5.0/3).
|-
|valign=top nowrap=true|'''TFTP Server:'''
| The TFTP server address.
|-
|valign=top nowrap=true|'''WINS Server:'''
| The WINS server address.
|-
|valign=top nowrap=true|'''Primary Gatekeeper *:'''
| The primary gatekeeper IP address.
|-
|valign=top nowrap=true|'''Secondary Gatekeeper *:'''
| The alternative Gatekeeper IP address.
|-
|valign=top nowrap=true|'''Coder *:'''
| Coder preference for VoIP telephones. In addition to the preference for the general coder, the preference for the local network coder can be specified here (since V6.00 SR1-hotfix3). G729A,60/G711A,30 for example defines G729A as the general coder and G711A as the local network coder.
You can enable SRTP on all phones by adding an "x" here like: G729A,60,x
|-
|valign=top nowrap=true|'''Gatekeeper Identifier *:'''
| The VoIP gatekeeper or the gatekeeper ID for VoIP telephones.
|-
|valign=top nowrap=true|'''Dial Tones *:'''
| The dial tone that is transmitted as the standard dial tone to the VoIP telephones (for example, German PBX = as German PBX, US = US dial tone, UK = British dial tone).
|-
|valign=top nowrap=true|'''Enblock Dialling Timeout [s] *:'''
| Switches on enbloc dialling for VoIP telephones.
|-
|valign=top nowrap=true|'''Faststart [0|1] *:'''
| Faststart 0/1 turns off/on the H.323 Faststart procedure. If this option is not defined the default (on) applies.
|-
|valign=top nowrap=true|'''Tunneling [0|1] *:'''
| Tunneling 0/1 turns off/on the H.245 Tunneling procedure. If this option is not defined the default (on) applies.
|-
|valign=top nowrap=true|'''Local Networks *:'''
| List of local networks in form of comma separated ''Address:Mask'' pairs (for example, 192.168.1.0:255.255.255.0,192.168.2.0:255.255.255.0). For VoIP Calls that end up in a local network the device will try to use the coder preferred for the local network (as provided in the Coder option or defined locally).
|-
|valign=top nowrap=true|'''Language *:'''
| All VoIP telephones that receive their IP-Adresse via DHCP have the language defined here set up as the standard language.
|-
|valign=top nowrap=true|'''Dialling Location *:'''
| Defines the various PBX access numbers on VoIP telephones for directory access. This character string must contain /cc, /ac, /ntp, /itp, /col and /pbx options. It may look like this: "/cc 49 /ac 7031 /ntp 0 /itp 00 /col 0 /pbx 7".
|-
|valign=top nowrap=true|'''AM/PM Clock [0|1]:'''
| Enables/disables the English time format for VoIP telephones. The German time format is displayed as standard: "dd.mm.yy hh:mm, 24-hour clock." If a 1 is entered in this field, the English time format "mm/dd hh:mm xm, 12-hour am/pm clock" is displayed.
|-
|valign=top nowrap=true|'''LDAP Directory:'''
| To allocate a functioning LDAP configuration to all VoIP devices integrated via DHCP, a configuration character string can be entered in the LDAP Directory field. You obtain this configuration character string by executing the following command in the browser of a configured device: "<IP-Adresse of the VoIP device>/!mod cmd PHONE DIR ldap-config". When this command has been executed, a configuration character string is output in the browser, which you copy and paste into the LDAP Directory field of the DHCP server. In this way, all further devices are given a correct LDAP configuration.
|-
|valign=top nowrap=true|'''Update Interval [min]:'''
| All devices integrated via DHCP are assigned the interval specified here in the Interval [min] field of the update server (see chapter entitled "[[Reference:Configuration/General/Update|Configuration/General/Update]]").
|-
|valign=top nowrap=true|'''Update Server URL:'''
| All devices integrated via DHCP are assigned the URL specified here (for example, <nowiki>http://192.168.1.2/update/script.htm</nowiki>) in the Command File URL field of the update server (see chapter entitled "[[Reference:Configuration/General/Update|Configuration/General/Update]]"). An automated update of the devices is thereby ensured.
|-
|valign=top nowrap=true|'''802.1q VLAN ID:'''
| The configuration at the switch must be observed for setting the VLAN ID. An empty 802.1q VLAN ID field (16 bit) assumes the value 0. The VLAN ID with the value 0 switches QoS (Quality of Service) off according to 802.1q ab. If the switch at the port to the innovaphone device happens to be configured to a different VLAN ID, the same value must be specified here to allow a prioritisation from the Ethernet. To be able to distinguish between the VLANs, the Ethernet packet is extended by 4 bytes, of which 12 bits are intended for the inclusion of the VLAN ID, making 4094 VLANs possible (VLAN ID 0 and 4095 are reserved or invalid).
|-
|valign=top nowrap=true|'''802.1p VLAN Priority'''
| In the 802.1p VLAN Priority field (3 bit), the associated VLAN priority level (a value between 0 and 7) can be specified, in order that voice data is given priority forwarding, for example.
|}

==DHCP Vendor-Optioncodes==

For a description howto implement the Innovaphone DHCP-Options in Microsoft or Linux DHCP Server Software refer to
[[Howto:DHCP client]]

Reference7:TAPI Service Provider

2009-08-19T06:02:54Z

Okoenigs:

The PBX supports a TAPI interface (also known as TSP ''Tapi Service Provider'').
From firmware version 7 on, there is an enhanced implementation of the service provider available.

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
* PBX, V7
Build 08-7030000 and later.

==More Information==

=== Enhancements ===
Previous TAPI service provider versions where restriced to a single PBX. That is, call- and user information was retrieved from one single PBX. Users registered in different PBXs (''slaves'') were not supported.
The V7 implementation supports master PBX with unlimited numbers of slaves attached, as well as standby PBXs.

The TSP uses HTTP/SOAP as a means of communication to the PBX(s). There used to be no support for HTTP/Digest Authentication resulting in an exposure of the clear password on the net. The V7 implementation supports HTTPS, which protects the password (as well as the entire communication).

===System Requirements===
The TSP will install on any Windows 32bit platform. The standard setup program provided will install the retail version. A debug version is available in the tapi/debug folder.
For 32bit Vista, the standard setup will fail. See [[Support:TAPI doesnt install under Windows Vista|the related wiki article for details]]. There is no support for 64bit operating systems.

=== Download ===
The V7 TSP will be available on the ''apps'' section of the [http://download.innovaphone.com/ice/7.00/ V7 download page].

===Installation===
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.

Microsoft’s Remote TAPI Server is currently not supported.

When the setup is done, your TSP is up and running, there is no need to go to the control panel. Also, it is recommended to use the setup instead of the control panel to de-install the TSP.

[[Image:TAPI Service Provider Setup1.png]]

While the folder where the TSP is installed to is of your choice, you should not install it into the windows system32 folder as other service provider do.

During the installation, the TAPI configuration dialog will be launched (see below).

===Upgrade===
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. Unfortunately, this will result in a new provider ID which
in turn may require you to re-configure some of the TAPI
applications using the TSP.

===Configuration===
The TSP configuration dialog looks like this:

[[Image:TAPI Service Provider Setup2.png]]

{| border=1
|-
| PBX - Master || The IP address or host name of the device the PBX is installed on
|-
| PBX - Standby || The IP address or host name of the device the PBX's standby is installed on. If there is no standby, leave this field empty. Do not enter any slave PBX here
|-
| PBX - Account || The PBX account name
|-
| PBX - Password || The accounts password
|-
| PBX - Use non-standard port || Tick this if your gateways http Server runs on a non-standard http port.
|-
| PBX - Use HTTPS || Tick this if you want to encrypt the PBX - TSP communication (recommended)
|-
| TAPI User - Username || Provide the Name of the PBX user the TSP shall work on behalf of
|-
| TAPI Line Names || The TSP will create a TAPI line device for each PBX user it sees. You can specify a template for the TAPI device name generated for each line. You can either choose one of the 3 pre-defined templates or create your own template (tick ''Use specified template'' and type your template into the template edit field)
|-
| Use pure node extensions || Tick this if the TSP shall report the pure intra-node extension as line address. Normally, the TSP would report the extension prefixed with the objects node number (and all node prefixes up to the root node).
|-
| Do not monitor slaves || Tick this if you don't want the TSP to monitor slave PBXs. This re-instates the V5 service provider behavior, except that standby PXS will be tracked anyway.
|}

The TAPI device name will be generated by substituting the following meta strings in the template

{|
|+
| Meta || Replacement
|+
| %c || The objects ''Long name'' (cn)
|+
| %d || The objects display name (dn)
|+
| %h || The objects ''Name'' (h323 alias)
|+
| %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)
|}

In a 1st party configuration, where the TSP is installed on a PC on
behalf of the PC’s user, you will typically use the users PBX name as
''Username''. In this case, you may use
the users PBX name as ''Account'' and provide the users PBX password.
Note that in this case, the user must have a password defined in the
PBX. In this scenario, configure the TSP to work with the PBX the user is known on. If it is a fully replicated scenario, you can use the master PBX. Otherwise use the PBX the user is defined on.

In a 3rd party configuration, where the TSP is installed on a server
acting on behalf of all network users, you will probably use a special
PBX user account which is an active member of a group in which all PBX
users which shall be seen by TAPI are members. You may for example
create an otherwise unused PBX user '''_TAPI_''' for this. You may use
the users ''Name'' as ''Account'' and its ''Long Name'' as ''Username''.
This users PBX password will be used as ''Password''.

Note that if you use a PBX user account as recommended, the user needs to have at least ''Group/Call Forwards'' rights.

In any case, the TSP will connect to the configured (master) PBX as well
as to all slaves and/or standbys seen by TAPI using the configured credentials (''PBX - Account'' and ''PBX - Password''). The configured account needs to be
present thus in all these PBXs. In a fully replicated scenario, this is
best done by leaving the ''PBX'' field of that user in the PBX user
configuration empty. This will result in a replication of all the user
data (including the password) to all PBXs.

To make sure TAPI sees all slaves, you need to include their ''node'' objects into the group monitored by TAPI (that is, the group '''_TAPI_''' user is an active member of).

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).

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 during the installation, the TSP will not be added and the software will not be installed.

When the configuration is OK you can configure the line to use in the TAPI application you intend to use.

Here is a screenshot of the respective Outlook configuration:

TBD

==== Working with multiple, unrelated PBXs ====
In a vanilla multi-node system, the TSP needs to know the masters and the (optional) stand-bys IP address only. The slaves are detected and connected automatically. This is done by analysis of the registration status of node objects in all 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 though. To support such a configuration, you will need to configure the extraneous master PBXs manually using regedit.

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

* open the key <code>HKEY_LOCAL_MACHINE\SOFTWARE\innovaphone\innovaphone® PBX V7 TSP</code>
* take note of the <code>installedProvider</code> entry (you will need the decimal value)
* open the key <code>HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Telephony\innovaphone® PBX V7 TAPI Service Provider</code>
* open its subkey <code>Device</code>''n'' where ''n'' is the decimal value of <code>installedProvider</code>
* Open the <code>FQDN</code> key and add all extra PBXs
* For those PBXs that have a standby PBX, add a value to the <code>StandbyFQDN</code> key (please note: these are parallel lists. So if master and standby need to have the same respective index in the <code>FQDN</code> and <code>StandbyFQDN</code> 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.

===User Configuration===
There is no special requirement regarding the PBX user configuration for the use of TAPI. Be aware though that a user that is not active in any group, will see only itself and thus only the TAPI line device which represents himself. To see the status of more PBX users, put the user as an active member into one or more groups.

The TSP is a PBX SOAP API based application. As such, the scope of
what the TAPI sees in terms of users follows the rules imposed by the
PBX. The TSP will issue exactly one
'''[[Reference:SOAP_API#Integer_Initialize.28string_user.2C_string_appl.2C_bool_v.2C_bool_v501.2C_out_int_key.29|Initialize]]'''
call for the user configured as ''PBX ACCESS USERNAME''. It will then
issue a
'''[[Reference:SOAP_API#integer_UserInitialize.28integer_session.2C_string_user.2C_bool_follow.29|UserInitialize]]'''
for each user. This is done on each PBX (master and slave/standbys).

==References==
The test applications provided with this setup comes from [http://www.julmar.com Julmar Technology Inc].

== Limitations ==
The current implementation will track slave PBXs coming and going and
updating call and user status accordingly. Also, standby PBXs
will be tracked correctly (that is, the
TSP will switch over between the PBX and its standby as required).

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). 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 doesn’t seem to run under 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.

* 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 <code>HKEY_LOCAL_MACHINE\SOFTWARE\innovaphone\innovaphone® PBX V7 TSP\lineGUIDs</code>) that maps the PBX's line GUID to a fixed integer value (known as ''permanent line id'' in TAPI speak). When a user previously seen by TAPI is removed from the PBX or moved out of the TAPI driver's scope, or the PBX that reported the user is off line, it will show up in TAPI as a '''defunct line (''old-name'')'''. To get rid of these lines, remove their corresponding registry entry.

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

=== Keys under HKEY_LOCAL_MACHINE\SOFTWARE\innovaphone\innovaphone® PBX V7 TSP ===

==== DoTraceFile ====
REG_DWORD. A debug TSP will write log files by default. Setting <code>DoTraceFile</code> to 0 will disable this. No effect in standard build.

==== ProcessorMask ====
REG_DWORD. If set, the TSP will use <code>SetProcessAffinityMask(GetCurrentProcess(), set)</code> to limit TSP execution to one of the existing processors. Set to 0x1 by default.

=== Keys under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Telephony\innovaphone® PBX V7 TAPI Service Provider ===
These are per-instance parameters found in a sub-tree of <code>HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Telephony\innovaphone® PBX V7 TAPI Service Provider</code> called <code>Device</code>''XX''.

==== 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 [http://www.estos.de/download/software/eccg.htm ESTOS' Call Control Gateway]: from version ''2.0.1.1474 - 05.11.2008'' there is a fix for this same problem available.

==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.

===Mandatory functions===
* TSPI_lineClose
* TSPI_lineCloseCall
* TSPI_lineGetAddressCaps
* TSPI_lineGetAddressID
* TSPI_lineGetAddressStatus
* TSPI_lineGetCallAddressID
* TSPI_lineGetCallInfo
* TSPI_lineGetCallStatus
* TSPI_lineGetDevCaps
* TSPI_lineGetID
* TSPI_lineGetLineDevStatus
* TSPI_lineGetNumAddressIDs
* TSPI_lineOpen
* TSPI_lineSetAppSpecific
* TSPI_lineSetCallParams
* TSPI_lineSetCurrentLocation
* TSPI_lineSetDefaultMediaDetection
* TSPI_lineSetMediaMode
* TSPI_lineSetStatusMessages
* TSPI_lineGetCallIDs
* TSPI_providerConfig
* TSPI_lineNegotiateTSPIVersion
* TSPI_providerUIIdentify
* TSPI_providerEnumDevices
* TSPI_providerShutdown
* TSPI_providerRemove
* TSPI_providerInstall

===Basic functions===
* TSPI_lineAnswer
* TSPI_lineDrop
* TSPI_lineMakeCall

===Supplementary features===
* TSPI_lineBlindTransfer
* TSPI_lineCompleteTransfer
* TSPI_lineForward
* TSPI_lineHold
* TSPI_lineUnhold
* TSPI_lineSwapHold
* TSPI_linePickup
* TSPI_lineRedirect

===Dynamic line creation===
* TSPI_providerCreateLineDevice

==Related Articles==
[[Howto:Troubleshooting the TAPI service provider]]

[[Support:TAPI doesnt install under Windows Vista]]

[[Support:TAPI fails on multi-processor system]]

[[Support:How should TAPI line device be registered?]]

[[Category:Howto|{{PAGENAME}}]]
[[Category:Concept|{{PAGENAME}}]]

Howto:Germany - HFO - HFO NGN Connect - SIP Provider(2015)

2009-05-31T07:50:04Z

Okoenigs: /* Contact */

==Product Name==

[http://www.hfo-telecom.de/geschaeftskunden/voip.php VoIP-Connect Business Voice]

==Certification Status==




{{Template:Compat Status "tested"}}


Testing of this product has been finalized October 22th, 2007.

==Category==

{{Category:RecProd SIP Provider}}
[[Category:RecProd SIP Provider]]

==Description==


==Remarks==


The provider supports all required innovaphone features and is therefore qualified as recommended SIP Provider.

HFO has achieved 89% of all possible test points. For more information on the tests results, please refer to:

[[Howto:HFO SIP Provider Compatibility Test|HFO Testreport]]

==Pricing==


==Contact==

http://www.hfo-telecom.de

[[Category:Compat|{{PAGENAME}}]]