innovaphone wiki - User contributions [en]

Howto:Volume levels on an IP50 or IP52, IP54

2008-10-16T09:17:00Z

Gpa: gpa - Kirk information ("Notice") über max. ringtone adjustment hinzugefügt

Volume Levels for Mic and Speaker Gain can be set on the handsets too.
==Applies To==
This information applies to

* IP 50
* IP 52
* IP 54

==More Information==
The volume on the handset is too low, although the speaker level is set to maximum via the volume keys.

===System Requirements===
Windows PC with serial interface

· Kirk Service Tool

. for download see related articel

· Programming cable

· IP50 programming cradle (DECT Charger with 3 Pins)

· IP52/54 programming cradle (DECT Charger with 3 Pins)

· Y-Connector

· Power Supply (for IP50 or IP52/54 DECT Charger)

===Installation===
Install the Kirk Service Tool following the instruction on the screen.

Connect the Y-Connector in the with on side to the docking station, on the other side connect the power supply and the programming cable to the connector.

Put the programming cable with the serial connector into the PC.

Plug in the Power Supply and insert a Handset to the cradle.

===Configuration===
In the Kirk Tool setup the following points:

· Communication Tab

. your COM Port

. PP1-PP4 … for IP50 Handsets

. PP5/40XX for IP52/54 Handsets

Put the Handset into the cradle and hit “set comport” in the Communications Tab. A Message like “PP connected” should appear in the bottom line of the Servic Tool Window.

Now go to the Gain Control Tabs, “Gain Control” for IP50 and “Gain Control 40XX” for IP52/IP54 Handsets. First read the old values from the Handset by pressing on “Read gain value” and adjust the values to your needs.

After that write them back to the Handset with pressing the “Write gain values”.

Turn the Handset off and on to re-read the new settings

'''Notice:'''
There are some different depending of the handsets maximum ringtone volume adjustment:
Within the Kirk service tool it is only possible to adjust the max. ringtone volume for IP50 Handsets.

IP50: Raising the maximum ringtone volume is possible.
IP52/54: It is not possible to adjust the max. ringtone volume on IP52 and IP54 Handsets!
The reason is that the ringing signal is send out in the same area where you have the loadspaker.
If for any reason someone helds the handsets to her/his ear, there is a limitation how high this signal can be.

==Related Articels==

[http://www.kirktelecom.com/Installer/suk205.asp service tool]

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

Howto:Configure external sound as MOH on IP21-AUX-Interface

2008-09-19T15:40:22Z

Gpa: gpa - Test mit mehreren PBXen fehlt.

How to implement external sound as music on hold (MOH) on the AUX interface of an IP21

==Applies To==
This information applies to

* all innovaphone PBXs and IP21

Build V6 and later

==More Information==
===Problem Details===
Often it is wanted to play a custom sound as music on hold.
For example a radio station will play their radio program while being on hold or a custom music should played from a mp3-player.

===Solution===
Within the AUX-interface of the IP21 there is the possibility to implement an '''''external sound''''' just by connecting a source like a mp3-player or a pc’s sound output device with the AUX interface of the IP21.

===Configuration===
====Single PBX====
'''Configure the PBX (e.g. IP800):'''
* Go to ''/PBX/General/'' and configure the string e.g. '''AUXMOH''' in the field ''External Music On Hold''
'''Configure the IP21:'''
* Go to ''/Gateway/Interfaces/AUX'' and configure the interface ''registration mode'' as '''H.323'''.
* Configure the interface name ''AUXMOH''
* Enable the ''MOH-mode''.
* Enter as ''Gatekeeper address'' the ip-address of the '''PBX'''.

====Multiple PBXs====
'''Configure the PBX (e.g. IP800):'''
* Go to ''/PBX/General/'' and configure the string e.g. '''AUXMOH''' in the field '''External Music On Hold'''
'''Configure the IP21:'''
* Go to ''/Gateway/Interfaces/AUX'' and configure the interface registration mode as ''H.323''.
* Configure the interface name '''AUX'''.
* Enable the '''MOH-mode'''.
* Enter as ''Gatekeeper address'' the local ip-address '''127.0.0.1'''.

* Go to ''/Gateway/VOIP/'' and configure an interface ''registration mode'' as '''Gatekeeper/Registrar'''
* Configure the interface ''Alias name'' '''AUX'''
--> this interface is used by the AUX-interface configured above to register on
* Configure for each ‘’PBX’’ an interface with ''registration mode'' '''Register as Gateway''' and as ''gatekeeper address'' the ip-address of the '''PBX'''
* Configure the interface ''alias'' name '''AUXMOH'''
--> these interfaces getting registered in the PBX.

* At least configure a route from all on the PBX registered interfaces/gateways to the interface/gateway of the type '''Gatekeeper/Registrar''' --> every call will be routed to the AUX interface now.

'''Note:''' It's important the '''''MOH-mode''''' flag has been enabled, otherwise only one MOH at the same time is possible.

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

Howto:Variable Length Extension Numbers

2008-08-13T12:31:18Z

Gpa: gpa - Howto use a mixed number lenght (orig. von Klaus W.) erstellt

==Summary==
An old and not solved problem in telephony is that a number can’t have a mixed length. If in a PBX for example exists the number 300” it isn’t possible to dial the number 3001 in that PBX. Up to now!
In a simple PBX a customer will not ask for something like that (hopefully), but imagine a network with more than one PBX. Where for example for “historical” reasons’ in two PBXes the “old” number should be conserved and of course the customer wants reach his colleague just dialing the well know number but now (in IP) without the ISDN prefix and so without any prefix.
For example the customer wants to dial “300” or “3000” and reach the extension “300” (local) or the (remote) extension “3000”. In older times no way, and you have to convince the customer to dial a prefix, similar to the ISDN, and so for example “83000” to reach the remote guy.
There are also scenarios like a legacy PBX connected to the innovaphone PBX, well know problems for an insider, where such a feature would be helpful.
With a simple XML script you can now realize a “mixed” numbering plan with the same starting digits.
Here is how to do that stuff.

==Applies To==
This information applies to
* All V6 PBX platforms
* Build v6 SR1 and later.

==More Information==
===Problem Details===
Of course also the innovaphone PBX will not accept mixed numbers with the same first digits. The basic problem is that dialing is a sequential issue, you dial one digit after the other and the question after each digit for a PBX is “is that the final destination or will other digits follow?”
If for example you want to mix 3 digits and 4 digits numbers (“300” and “3000”) the solution is to wait, in your application, until the 4rd digit is entered. At the end of the story you force a kind of “block dial” for that specific numbers and that is a limit, but the customer will understand that (how should otherwise the system know?).

===System Requirements===
The feature is based on an XML script typically installed on the compact flash, it will work also on external Webdav sever.

===Installation===
You have to create a VM Object pointing on the XML script. The number of the VM Object has to fit with your unique numbering plan.
Example: If in a PBX exist the number 330 in the same scenario you want to reach a remote user just dialing 3301 you have to capture the number 330 and so your VM Object hat to have that number.

===XML analysis===
The code of the XML is quite simple and can easily be modified. Please note that all the XML commands and even the structure is well described in the file “schema” which you will find in every innovaphone Voice-Mail installation.
The XML performs the following steps:
• captures the digits
• controls if the configured number length is reached (in our code example: 3 (digits))
• waits for the dialing time-out (5 seconds)
Now there are two cases: the number length is longer than the threshold of 3 or not, if yes the XML will insert an additional number (for example “8”) and transfer the call to that number (so to the number “83301”). Of course in the PBX you will have a connection to the far PBX with the prefix “8” and the job is done.
In the timeout case the XML will just transfer the call to the number (“330”) and the extension will ring.

Code discussion (comment in cursive):

<?xml version="1.0" encoding="utf-8" ?> the usual header stuff
<voicemail>

<function define="Main">

<assign out="$CodeLen" value="3"/> Here you define the length of the digits, insert the number

<assign out="$Prefix" value="8"/> And here is the prefix to insert, in our example 8
<assign out="$call" value=""/> now first the variable $call is cleared
<call name="CheckLEN"/> and than the real function is called
<pbx-disc/> and that’s it.
</function>
<function define="CheckLEN"> here starts the function
<wait sec="5"/> here you con define the timout, 5 seconds in our example
<pbx-getcallinfo out-cgpn="$cgpn" out-cdpn="$cdpn" out-leg2="$leg2"/> get the dialing information from the pbx
<lib-strlen out="$res" string="$cdpn"/> and copy it in the $res variable
<switch var="$res"> and than check the length of the dialed number
<case equal="$CodeLen"> if the length is equal the threshold
<assign out="$call" value="$cdpn"/> just copy the dialed number in the $call variable
</case>
<case not-equal="$CodeLen"> otherwise if the length is not equal copy the prefix
<lib-strcat string="$Prefix" string2="$cdpn" out-string="$call" /> and the dialed number in the $call variable
</case>
</switch>
<pbx-fwd e164="$call" out-cause="$cause"/> and than transfer in both cases the call to the destination, witch means to the content of the $call variable
</function>
</voicemail>

Here again the code without any comment to copy in the xml object:

<?xml version="1.0" encoding="utf-8" ?>
<voicemail>

<function define="Main">

<assign out="$CodeLen" value="3"/>

<assign out="$Prefix" value="0"/>
<assign out="$call" value=""/>
<call name="CheckLEN"/>
<pbx-disc/>
</function>
<function define="CheckLEN">
<wait sec="5"/>
<pbx-getcallinfo out-cgpn="$cgpn" out-cdpn="$cdpn" out-leg2="$leg2"/>
<lib-strlen out="$res" string="$cdpn"/>
<switch var="$res">
<case equal="$CodeLen">
<assign out="$call" value="$cdpn"/>
</case>
<case not-equal="$CodeLen">
<lib-strcat string="$Prefix" string2="$cdpn" out-string="$call" />
</case>
</switch>
<pbx-fwd e164="$call" out-cause="$cause"/>
</function>
</voicemail>

But you can also copy the XML file on your CF and edit it there.
Please feel free to modify as you like.

===Known Problems===
Please note that for die Number 330 and 330x the behavior now will be “block dialing” with timeout.

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

Howto:Restricted trunk access via 2-stage dialling

2008-04-23T15:00:50Z

Gpa: gpa - Formatierung ein wenig angepasst

This article describes how to give restricted extensions the possibility to make external calls through the innovaphone operator and the waiting queue object.

==Applies To==
This information applies to

* innovaphone operator
Build 5967 and later.
* all innovaphone telephones and gateways
Build v5.01 and later

==More Information==
===Problem===
Direct access to the trunk line is forbidden by internal policy for normal extensions.
Direct access to the trunk line is possible via permitted extensions such as an operator is.

===Solution===
The operators are allowed to grant trunk line access to extensions, which aren’t authorized to call external numbers.
The solution is based on the 2-stage dialling concept:

* At first call the operator. The operator will transfer the call to the waiting queue object, which is allowed by filter to access the trunk line.
* Then dial the trunk line prefix (e.g. 0 or 9) and right after that the wanted external number

===Scenario===
This solution is taking following is-state:
* It exists an operator '''88:Operator'''
* It exists a trunk object '''0:Trunk'''
* It exists an user object '''100:Hans'''

===Configuration===
* Create a waiting queue object '''99:WQ''', needed for the 2-stage dialling
* Deny access to the waiting queue ('''99:WQ''') by filter to all extensions (e.g. '''100:Hans''')
* Deny access to the trunk line ('''0:Trunk''') by filter to all extensions (e.g. '''100:Hans''')
* Permit access to the operator ('''88:OP''') by filter to all extensions (e.g. '''100:Hans''')
* Permit access to the trunk line ('''0:Trunk''') for the operator ('''88:OP''')

===Administration===
Create the waiting queue object under "''Administration/PBX/Objects''".
* Enter '''WQ''' as ''Name'' and ''Long Name''. Enter '''99''' as ''Number''
* Enter '''0''' as ''Alert Timeout''.
* Enter '''0''' or '''9''' as ''DTMF Number'. Enter '''0''' as ''Dest. No''.

Extend the existing filter '''''normal''''' under "''Administration/PBX/Filter''".
'''Note:''' The '''''normal''''' filter is the default filter of all pbx-objects,
so the restriction of all user-objects is given within the '''''normal''''' filter.
* A filter to deny the dial of the '''0:Trunk''' directly
* A filter to deny the dial of the '''99:WQ''' directly
* A filter to permit the dial of the '''88:OP''' directly

Create a new filter '''''operator''''' under "''Administration/PBX/Filter''".
'''Note:''' The '''''operator''''' filter is the filter for the operator object.
It will remove the restriction for the operator to access the waiting queue,
so he’s the only one who can access the waiting queue.
* A filter to permit the dial of the waiting queue '''99:WQ''' directly (only for the Operator)

Assign the '''''operator''''' filter under "''Administration/PBX/Objects''"
* Open up the object '''88:OP'''
* As filter select '''''operator'''''

==Test==
===Positiv===
* '''100:Hans''' is dialling '''88:Operator''' requesting for a trunk line
* '''88:Operator''' accepts the call and transfer it to '''99:WQ'''
* '''100:Hans''' is allowed to dial his wanted number (e.g. 07031-12345) via DTMF now, initialized by the DTMF Number '''0''' or '''9''' (so it is 007031-12345)
* '''CDRs''' will be generated with '''Hans:100''' as origination (..src_cgpn=100&src_name=Hans..). Such that '''Hans''' is going to be charged.

===Negative===
* '''100:Hans''' dials '''0:Trunk''' directly -> call is getting rejected
* '''100:Hans''' dials '''99:WQ''' directly -> call is getting rejected

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

Howto:Restricted trunk access via 2-stage dialling

2008-04-22T10:22:36Z

Gpa:

This article describes how to give restricted extensions the possibility to make external calls through the innovaphone operator and the waiting queue object.

==Applies To==
This information applies to

* innovaphone operator
Build 5967 and later.
* all innovaphone telephones and gateways
Build v5.01 and later

==More Information==
===Problem===
Direct access to the trunk line is forbidden by internal policy for normal extensions.
Direct access to the trunk line is possible via permitted extensions such as an operator is.

===Solution===
The operators are allowed to grant trunk line access to extensions, which aren’t authorized to call external numbers.
The solution is based on the 2-stage dialling concept:

* At first call the operator. The operator will transfer the call to the waiting queue object, which is allowed by filter to access the trunk line.
* Then dial the trunk line prefix (e.g. 0 or 9) and right after that the wanted external number

===Scenario===
This solution is taking following is-state:
* It exists an operator '''88:Operator'''
* It exists a trunk object '''0:Trunk'''
* It exists an user object '''100:Hans'''

===Configuration===
* Create a waiting queue object '''99:WQ''', needed for the 2-stage dialling
* Deny access to the waiting queue ('''99:WQ''') by filter to all extensions (e.g. '''100:Hans''')
* Deny access to the trunk line ('''0:Trunk''') by filter to all extensions (e.g. '''100:Hans''')
* Permit access to the operator ('''88:OP''') by filter to all extensions (e.g. '''100:Hans''')
* Permit access to the trunk line ('''0:Trunk''') for the operator ('''88:OP''')

===Administration===
Create the waiting queue object under "''Administration/PBX/Objects''".
* Enter '''WQ''' as ''Name'' and ''Long Name''. Enter '''99''' as ''Number''
* Enter '''0''' as ''Alert Timeout''.
* Enter '''0''' or '''9''' as ''DTMF Number'. Enter '''0''' as ''Dest. No''.

Extend the existing filter '''''normal''''' under "''Administration/PBX/Filter''".
'''Note:''' The '''''normal''''' filter is the default filter of all pbx-objects,
so the restriction of all user-objects is given within the '''''normal''''' filter.
* A filter to deny the dial of the '''0:Trunk''' directly
* A filter to deny the dial of the '''99:WQ''' directly
* A filter to permit the dial of the '''88:OP''' directly

Create a new filter '''''operator''''' under "''Administration/PBX/Filter''".
'''Note:''' The '''''operator''''' filter is the filter for the operator object.
It will remove the restriction for the operator to access the waiting queue,
so he’s the only one who can access the waiting queue.
* A filter to permit the dial of the waiting queue '''99:WQ''' directly (only for the Operator)

Assign the '''''operator''''' filter under "''Administration/PBX/Objects''"
* Open up the object '''88:OP'''
* As filter select '''''operator'''''

==Test==
===Positiv===
* '''100:Hans''' is dialling '''88:Operator''' requesting for a trunk line
* '''88:Operator''' accepts the call and transfer it to '''99:WQ'''
* '''100:Hans''' is now able to dial his wanted number (e.g. 07031-12345) via DTMF, initialized by the DTMF Number '''0''' or '''9''' (so it is 007031-12345)

===Negative===
* '''100:Hans''' dials '''0:Trunk''' directly -> call is getting rejected
* '''100:Hans''' dials '''99:WQ''' directly -> call is getting rejected

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

Howto:Restricted trunk access via 2-stage dialling

2008-04-22T10:16:10Z

Gpa: gpa - Restriced trunk line access via stage dialling angepasst

This article describes how to give restricted extensions the possibility to make external calls through the innovaphone operator and the waiting queue object.

==Applies To==
This information applies to

* innovaphone operator
Build 5967 and later.
* all innovaphone telephones and gateways
Build v5.01 and later

==More Information==
=== Problem ===
Direct access to the trunk line is forbidden by internal policy for normal extensions.
Direct access to the trunk line is possible via permitted extensions such as an operator is.

=== Solution ===
The operators are allowed to grant trunk line access to extensions, which aren’t authorized to call external numbers.
The solution is based on the 2-stage dialling concept:

* At first call the operator. The operator will transfer the call to the waiting queue object, which is allowed by filter to access the trunk line via dtmf-tone.
* Then dial the trunk line prefix (e.g. 0 or 9) and right after that the wanted external number

===Szenario===
This solution is taking following is-state:
* It exists an operator '''88:Operator'''
* It exists a trunk object '''0:Trunk'''
* It exists an user object '''100:Hans'''

===Configuration===
* Create a waiting queue object '''99:WQ''', needed for the 2-stage dialling
* Deny access to the waiting queue ('''99:WQ''') by filter to all extensions (e.g. '''100:Hans''')
* Deny access to the trunk line ('''0:Trunk''') by filter to all extensions (e.g. '''100:Hans''')
* Permit access to the operator ('''88:OP''') by filter to all extensions (e.g. '''100:Hans''')
* Permit access to the trunk line ('''0:Trunk''') for the operator ('''88:OP''')

===Administration===
Create the waiting queue object under "''Administration/PBX/Objects''".
* Enter '''WQ''' as ''Name'' and ''Long Name''. Enter '''99''' as ''Number''
* Enter '''0''' as ''Alert Timeout''.
* Enter '''0''' or '''9''' as ''DTMF Number'. Enter '''0''' as ''Dest. No''.

Extend the existing filter '''''normal''''' under "''Administration/PBX/Filter''".
'''Note:''' The '''''normal''''' filter is the default filter of all pbx-objects,
so the restriction of all user-objects is given within the '''''normal''''' filter.
* A filter to deny the dial of the '''0:Trunk''' directly
* A filter to deny the dial of the '''99:WQ''' directly
* A filter to permit the dial of the '''88:OP''' directly

Create a new filter '''''operator''''' under "''Administration/PBX/Filter''".
'''Note:''' The '''''operator''''' filter is the filter for the operator object.
It will remove the restriction for the operator to access the waiting queue,
so he’s the only one who can access the waiting queue.
* A filter to permit the dial of the waiting queue '''99:WQ''' directly (only for the Operator)

Assign the '''''operator''''' filter under "''Administration/PBX/Objects''"
* Open up the object '''88:OP'''
* As filter select '''''operator'''''

==Test==
===Positiv===
* '''100:Hans''' is dialling '''88:Operator''' requesting for a trunk line
* '''88:Operator''' accepts the call and transfer it to '''99:WQ'''
* '''100:Hans''' is now able to dial his wanted number (e.g. 07031-12345) via DTMF, initialized by the DTMF Number '''0''' or '''9''' (so it is 007031-12345)

===Negative===
* '''100:Hans''' dials '''0:Trunk''' directly -> call is getting rejected
* '''100:Hans''' dials '''99:WQ''' directly -> call is getting rejected

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

Howto:Restricted trunk access via 2-stage dialling

2008-04-22T09:02:32Z

Gpa: Howto:Howto Trunk-Access-via-WQ-and-2stage-dialling moved to Howto:Restricted trunk access via 2-stage dialling: Howto mit Restricted im Titel ersetzt und WQ entfernt.

This article describes how to give restricted extensions the possibility to make external calls through the innovaphone operator.

==Applies To==
This information applies to

* innovaphone operator
Build 5967 and later.
* all innovaphone telephones and gateways
Build V6 SR2HF1 and later

==More Information==
=== Problem ===
Direct access to the trunk line is forbidden for normal ip-clients by internal policy.
Direct access to the trunk line is possible via permitted ip-clients such as an operator is.
The operators are allowed to grant trunk line access to extensions (ip-clients), which aren’t authorized to call external numbers.

=== Solution ===
The solution is based on the waiting queue object, which gives restricted ip-clients access to the trunk line for outgoing calls. The restricted ip-clients will be transferred to this object by a permitted ip-client (operator). After that, dialling via DTMF is possible.

* The internals will request for a trunk line by making a call to the operator.
* The operator will transfer the call to the waiting queue object – giving away the responsibility about that call.
* Restrict access to the waiting queue object by filter. Only the operator should be able to call the waiting queue.

===Szenario===
This solution is taking following is-state:
* It exists an operator '''88:Operator'''
* It exists a trunk object '''0:Trunk'''
* It exists an user object '''100:Hans'''

===Administration===
* Create a waiting queue object '''99:WQ''', needed for the 2-stage dialling
* Deny access to the waiting queue ('''99:WQ''') by filter to all ip-clients (e.g. '''100:Hans''')
* Deny access to the trunk line ('''0:Trunk''') by filter to all ip-clients (e.g. '''100:Hans''')
* Permit access to the operator ('''88:OP''') by filter to all ip-clients (e.g. '''100:Hans''')
Doing this by extending the '''''normal''''' filter with '''0 -> nok''', '''99 -> nok''' and '''88 -> ok'''
* Permit access to the trunk line ('''0:Trunk''') by filter to the ip-client operator (e.g. '''88:OP''') by creating a new filter '''''operator''''' '''0 -> ok''' and assigning this filter to the operator (e.g. '''88:OP''').

===Configuration ===
Extend the existing filter '''''normal''''' under "Administration/PBX/Filter". Note: The '''''normal''''' filter is the default filter of all pbx-objects, so the restriction of all user-objects is given within the '''''normal''''' filter.
* A filter to deny the dial of the '''0:Trunk''' directly
* A filter to deny the dial of the '''99:WQ''' directly
* A filter to permit the dial of the '''88:OP''' directly

Create a new filter '''''operator''''' under "Administration/PBX/Filter". Note: The '''''operator''''' filter is the filter for the operator object. It will remove the restriction for the operator to access the waiting queue, so he’s the only one who can access the waiting queue.
* A filter to permit the dial of the waiting queue '''99:WQ''' directly (only for the Operator)

Assign the '''''operator''''' filter under "Administration/PBX/Objects"
* Open up the object '''88:OP'''
* As filter select '''''operator'''''

Create the WQ object under "Administration/PBX/Objects".
* Enter '''WQ''' as Name and Long Name. Enter '''99''' as Number
* Enter '''0''' as Alert Timeout.
* Enter '''0''' or '''9''' as DTMF Number. Enter '''0''' as Dest. No.

==Test==
===Positiv===
* '''100:Hans''' is dialling '''88:Operator''' requesting for a trunk line
* '''88:Operator''' accepts the call and transfer it to '''99:WQ'''
* '''100:Hans''' is now able to dial his wanted number (e.g. 07031-12345) via DTMF, initialized by the DTMF Number '''0''' or '''9'''

===Negative===
* '''100:Hans''' dials '''0:Trunk''' directly -> call is getting rejected
* '''100:Hans''' dials '''99:WQ''' directly -> call is getting rejected

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

Howto:Restricted trunk access via 2-stage dialling

2008-04-21T11:55:54Z

Gpa: gpa - Artikel "Howto trunk access via waiting queue and 2stage dialling" erstellt

Reference:Administration/Reset/TFTP

2008-04-16T10:29:05Z

Gpa: gpa - link zur inno-kb entfernt und auf wiki-artikel verwiesen

With a '''TFTP Reset''', the VoIP device is transferred to TFTP mode. In this mode, the device can only be accessed with the GWLoad tool and thus allocated an IP-Adresse. Further information on the innovaphone GWLoad tool can be found here: [[Howto:How_to_use_gwload | How_to_use_gwload]].

Reference:Configuration/DECT/Master

2008-04-03T12:58:26Z

Gpa:

It is necessary to configure the operating mode of the DECT system. A gatekeeper must also be specified here, on which the innovaphone PBX component is operated.

* '''Mode:''' Active switches on the DECT master function. In every DECT system, there must be a DECT master.
** '''Off''' switches off the DECT master function.
** '''Active''' switches on the DECT master function.
** '''Standby''' switches on the standby function for the DECT master.
* '''Primary Master IP Address:''' This field is only visible if this device has been configured as Standby-Master ('''''Mode'' = ''Standby'''''). The IP address of the DECT-Master has to be configured here.
* '''GK:''' The IP address of the primary gatekeeper. The device on which the innovaphone PBX component is operated.
* '''Alt GK:''' The IP address of the secondary, alternative gatekeeper.
* '''GK ID:''' The gatekeeper ID of the gatekeeper to be used.
* '''Prot:''' The protocol to be used for the communication. There is a choice between:
** '''H.323''' (RFC 1889), which is the recommended protocol for innovaphone VoIP devices, since it implements most features.
** '''SIP''' (RFC 3261).
* '''STUN Server:''' STUN server to be used if DECT master has no public ip address and SIP server is outside the local network.
* '''Name for Authentication:''' Some SIP PBXs need authentication name different from the registration id. This enables the number being used as id and the name for authentication.
* '''Master ID:''' If this device is configured as master, the unique id of it can be configured here. This gives the possibility to register phones to a user on another DECT master in the case that in the radios has been configured multiple masters.
'''Example:'''
A dect phone dials the number (e.g. 100) of a dect-user object (master1, id=1) to register in.
If it exists another user (e.g. 101) on another master (master2, id=2) configured as an additional master in the radios,
this user can get registered now by dialling '''*<master-id>*101 --> *2*101'''

Reference:Configuration/DECT/Master

2008-04-03T12:57:03Z

Gpa:

It is necessary to configure the operating mode of the DECT system. A gatekeeper must also be specified here, on which the innovaphone PBX component is operated.

* '''Mode:''' Active switches on the DECT master function. In every DECT system, there must be a DECT master.
** '''Off''' switches off the DECT master function.
** '''Active''' switches on the DECT master function.
** '''Standby''' switches on the standby function for the DECT master.
* '''Primary Master IP Address:''' This field is only visible if this device has been configured as Standby-Master ('''''Mode'' = ''Standby'''''). The IP address of the DECT-Master has to be configured here.
* '''GK:''' The IP address of the primary gatekeeper. The device on which the innovaphone PBX component is operated.
* '''Alt GK:''' The IP address of the secondary, alternative gatekeeper.
* '''GK ID:''' The gatekeeper ID of the gatekeeper to be used.
* '''Prot:''' The protocol to be used for the communication. There is a choice between:
** '''H.323''' (RFC 1889), which is the recommended protocol for innovaphone VoIP devices, since it implements most features.
** '''SIP''' (RFC 3261).
* '''STUN Server:''' STUN server to be used if DECT master has no public ip address and SIP server is outside the local network.
* '''Name for Authentication:''' Some SIP PBXs need authentication name different from the registration id. This enables the number being used as id and the name for authentication.
* '''Master ID:''' If this device is configured as master, the unique id of it can be configured here. This gives the possibility to register phones to a user on another DECT master in the case that in the radios has been configured multiple masters.
'''Example:'''
A dect phone dials the number (e.g. 100) of a dect-user object (master1, id=1) to register in.
If it exists another user (e.g. 101) on another master (master2, id=2) configured as an additional master in the radios, this user can get registered now
by dialling '''*<master-id>*101 --> *2*101'''

Reference:Configuration/DECT/Radio

2008-04-03T11:40:05Z

Gpa: gpa - Beschreibung zu neuen Menüpunkten ergänzt

In this menu, the DECT system can be configured as a '''DECT radio''', provided that a DECT master was already configured.

* '''Disable:''' A checked check box disables the DECT radio (cell).
* '''Master:''' The IP address of the DECT master. If the device itself was defined as the DECT master, then no IP address has to be entered here. The local IP address 127.0.0.1 is automatically entered.
* '''Alt Master:''' The IP address of the standby master.
* '''Radio ID:'''
** In '''Singlecell''' operation, the radio ID 0 must be specified.
** In '''Multicell''' operation, every radio must have a unique ID. The ID must lie in the range 0 - Sys-Mask (with Sys-Mask specification) or 0 - 254 (without Sys-Mask specification).
* '''Sync source:''' The radio ID with which the radio is to synchronise.
* '''Alt Sync Source:''' The radio ID with which the radio is to synchronise in the event that the sync master is not accessible. Here, it is to be noted that no loops must be created. In other words, if a sync master exists with the radio ID 1 and an alt sync master exists with the radio ID 3, then the alt sync master must on no account synchronise with any radio, since the radio synchronises with the alt sync master in the event of failure of the sync master.

==Master==
For configuration of DECT-Radios it is needed to specify explicit the ip-address of the DECT-Master here and if present also of the Standby-DECT-Master. Name and Password needs to get configured if the device is only DECT-Radio and not registered to a local DECT-Master. This Name and Password is equivalent to Name and Password of the external DECT-Master configured under "Configuration/DECT/System".

==Additional Master==
DECT-Radios can now register to several DECT-Masters and receive their user data. Within this option it is possible to distribute the user data and the registration at the pbx among the devices.
Neu ist, dass sich ein Radio an mehreren Mastern anmelden kann und von allen mit Benutzerdaten versorgt wird; dies ermöglich, dass man die Teilnehmer auf unterschiedliche Geräte verteilen kann, um die Anmeldungen zur PBX auf einzelne Geräte zu verteilen.

Reference:Configuration/DECT/Master

2008-04-03T10:56:10Z

Gpa: gpa - Beschreibung zu neuen Menüpunkten ergänzt

It is necessary to configure the operating mode of the DECT system. A gatekeeper must also be specified here, on which the innovaphone PBX component is operated.

* '''Mode:''' Active switches on the DECT master function. In every DECT system, there must be a DECT master.
** '''Standby''' switches on the standby function for the DECT master.
** '''Off''' switches off the DECT master function.
* '''Primary Master IP Address:''' This field is only visible if this device has been set to Standby-Master ('''''Mode'' = ''Standby'''''). The ip-address of the DECT-Master has to be configured here.
* '''GK:''' The IP address of the primary gatekeeper. The device on which the innovaphone PBX component is operated.
* '''Alt GK:''' The IP address of the secondary, alternative gatekeeper.
* '''GK ID:''' The gatekeeper ID of the gatekeeper to be used.
* '''Prot:''' The protocol to be used for the communication. There is a choice between:
** '''H.323''' (RFC 1889), which is the recommended protocol for innovaphone VoIP devices, since it implements most features.
** '''SIP''' (RFC 3261).
* '''STUN Server:''' STUN server to be used if DECT master has no public ip address and SIP server is outside the local network.
* '''Name for Authentication:''' Some SIP PBXs need authentication name different from the registration id. This enables the number being used as id and the name for authentication.
* '''Master ID:''' If this device is configured as master, the unique id of it will be configured here. This gives the possibility to register phones on another master pbx.
'''Example:'''
A dect phone dials the number (e.g. 100) of a dect-user object (pbx1, id=1) to register in.
If it exists another user (e.g. 101) on another pbx (pbx2, id=2), this user can get registered now
by dialling '''*<master-id>*101 --> *2*101'''

Howto:MWI in Version 5.01 nach H.405.7 in IXI-UMS

2008-01-30T19:18:41Z

Gpa: gpa Knowledgebase Artikel Q10117 importiert

'''FAQ:'''
MWI in Version 5.01 nach H.405.7 in IXI-UMS

'''Answer:'''
Neither the IP200 nor IXI-UMS currently support MWI as per H.450.7 (although the IP100 does).

IXI-UMS features a new MWI feature based on the IP200's call list in the latest full version though. We are currently reviewing this feature. Stay tuned.



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

Howto:How to use media-relay functionality for sip-registrations and how to configure sip-clients and sip-trunk

2008-01-30T19:08:59Z

Gpa: gpa Knowledgebase Artikel Q10672 importiert

==Summary==
This document describes how to configure a sip-user on telephones and a sip-trunk-line in the innovaphone-PBX! It also describes how to configure the media-relay functionality.

==Applies To==
This information applies to

* IP 3000, V4
* IP 400, V4
* IP 21, V4
Build 01-4001 and later.



==More Information==
===Problem Details===

1. Regarding media-relay functionality

a. Due to its special trickiness here is a small guideline on the configuration of SIP trunk interfaces towards the public internet. This concerns "Register as "interfaces to a SIP provider as well as interfaces without registration (e.g. ENUM).

b. Let's start discussion with a quick look at internal-only telephony. Afterwards we're going to add a SIP trunk to our installation.

### Internal IP telephony

Sig Sig
+------------->PBX<------------+
| |
EP <------------------------> EP
RTP

On the internal-only-telephony the RTP streams go always end-to-end between the talking endpoints, not through the PBX in between. The PBX simply forwards the internal RTP address of each endpoint to the other side. This is done for scalability resaons.

### Internal IP telephony with external VOIP trunk

Sig Sig Sig :
+------------->PBX<----------->GATEWAY<---------:----------+
| : |
EP <----------------------------->|<------------:-------> EP
RTP RTP :
:
(private network) : (public network)

c. Internal IP telephony with external VOIP trunk
The gateway with the VOIP interface towards the external/public internet must have a public ip-address. Either a real public ip-address on one of its ip interfaces or a mapped public ip-address by means of STUN.
In opposite to the internal-only-telephony where the RTP streams go directly between the talking endpoints, the gateway must not give the RTP address of the internal endpoint to the external endpoint, since the external endpoint cannot send to that internal ip-address. The gateway must rather give its own public ip-address to the external endpoint. The gateway then receives RTP from the external endpoint on its public ip address and forwards it to the internal endpoint. This is what we call "media-relay".

In order to use the media-relay functionality, the gateway must be able to recognize sessions between internal and external endpoints. To achieve that the gateway must know the address range of the internal network.
System Requirements

V6 Build on gateways and telephones is absolutely needed.

An existing sip-account is needed. For example a user with user-id (URI) 8111111e0@sipgate.de. and password 1234.
Configuration

1. Configuring the media-relay functionality

a. The administrator must configure this ip-address range on: IP/Settings/Private Networks. In addition to the real internal network addresses, the internal loopback address range must be configured there. Example:
192.168.0.0 / 255.255.255.0
127.0.0.0 / 255.255.255.0

2. Configuring a sip-user to an innovaphone VoIP-Telephone

a. Go to the telephone web-interface and switch to Configuration/Registrationx/Registration tab and enable it.

b. As Protocol select SIP

c. As primary ip-address you can enter the sip-provider ip-address there if want to send the REGISTER request to another than configured in domain. This is not needed if a domain is configured because the ip-address could be resolved from the entered domain (DNS). If you want to use the domain only for the SIP-URI creation and send the REGISTER to an specific ip-address enter an ip-address and it will override the domain, without doing any DNS resolving. If your sip-provider supports a secondary ip-address you can configure an alternative ip-address if the primary ip-address isnt available.

d. Defines the local ip-address, the telephone uses for registration. This setting is only for exceptional cases.

e. As domain enter the sip-provider web-address (e.g. sipgate.de) which you can find in the uri-string (term behind @) given by the sip-provider.

f. As user-id enter the number (e.g. 8111111e0) which you can find in the uri-string (term before @) given by the sip-provider (e.g. 1234).

g. As stun server enter the stun-server web-address given by the sip-provider.

h. For correct authorisation enter the user-name (user-id) and password into the Authorization fieldset.

i. After clicking OK the state should be up displayed in the right upper corner.
Notice a sip-call dont support dial-tones. You need to enter the wished number before dialling.

3. Configuring a sip-trunk-line to an innovaphone VoIP-Gateway

a. First configure a pbx-object trunk e.g. with h.323-name SIPTrunk and E.164-number 8.

b. Then go to Administration/Gateway/Interfaces and select on of the SIPx-interfaces.

c. Enter a descriptive name.

d. As primary ip-address you can enter the sip-provider ip-address there if want to send the REGISTER request to another than configured in domain. This is not needed if a domain is configured because the ip-address could be resolved from the entered domain (DNS). If you want to use the domain only for the SIP-URI creation and send the REGISTER to an specific ip-address enter an ip-address and it will override the domain, without doing any DNS resolving. If your sip-provider supports a secondary ip-address you can configure an alternative ip-address if the primary ip-address isnt available.

e. As ID configure the number (e.g. 8111111e0) which you can find in the uri-string (term before @) given by the sip-provider. Behind the @-symbol enter the sip-provider web-address (e.g. sipgate.de) which you can find in the uri-string (term behind @) given by the sip-provider.

f. As account enter the user-id (e.g. 8111111e0) which you can find in the uri-string (term before @) given by the sip-provider.

g. As stun server enter the stun-server web-address given by the sip-provider.

h. If Account is not set, this Name (part in the uri-string before the @-symbol) is used for the registration.

i. As Account enter the user-id (e.g. 8111111e0) which you can find in the uri-string (term before @) given by the sip-provider.

j. For correct authorisation enter the password (e.g. 1234) of the sip-account in the password field and retype it.

k. Now it is needed to bind this sip-registration to a pbx-sip-trunk-line. To get this work enable the h.323-registration and configure the primary and if existing the secondary gatekeeper ip-address (e.g. 127.0.0.1 if the pbx is running on the same device). It is adequate to configure only the gatekeeper-id.

l. At least the information of the h.323-name or e.164-number is needed.
m. After clicking OK the state should display the ip-address of the sip-provider. As alias it should display the name and number of the pbx-trunk-object (e.g. SIPTrunk:8). Under registration the ip-address of the pbx (e.g. 127.0.0.1) is displayed.
In the pbx-object-overview the trunk-line-object should also be registered.
Notice a sip-call dont support dial-tones. You need to enter the wished number before dialling.

===Known Problems===
1. Regarding media-relay functionality
Working with giving private ip-addresses to the outside world could work under some very special circumstances, but is not recommended! You probably will have strange problems like "one way media" or "dying registrations" or "no incoming calls".

2. Regarding IP202
The ip202 doesnt have a pbx component anymore. So it is only possible to register this phone to a sip-account. It is not possible to use this phone as sip-server (registering sip-telephones to this phone) or to configure it as sip-trunk-line.

== Related Articles ==
*[[Howto:Does_Innovaphone_Gateway_with_v.6_firmware_support_RFC_2833_to_provide_SIP_DTMF_relay%3F_Thanks.]]
*[[Howto:What_Ports_are_used_for_Signaling_and_Voice_Traffic_in_SIP_and_H.323%3F]]
*[[Howto:Supported_SIP_Features_and_List_of_RFC%27s]]
*[[Howto:How_to_interpret_SIP_error_codes_returned_by_the_innovaphone_SIP_stack]]
*[[Howto:Is_Fax_supported_with_SIP_VoIP_interfaces%3F_Thanks]]

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

Howto:For how many phones can an ip3000 be dhcp server be used

2008-01-30T18:15:23Z

Gpa:

==Summary==
Maximum users for an innovaphone DHCP Server

==Applies To==
This information applies to
* IP3000
* IP800

'''FAQ:'''
For how many phones can an ip3000 be dhcp server be used

'''Answer:'''
The restriction for the amount of dhcp leases is the limitation of memory segments for VARs.

Normally a single segment has 64 kB (128 kB at the IP800). An entry has 84 Byte -> 65536/64 = 1024. Due to the fact that there aren’t only dhcp leases in the VAR segment, an amount of nearly 800 leases will be realistic.



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

Howto:For how many phones can an ip3000 be dhcp server be used

2008-01-30T18:14:32Z

Gpa: gpa Knowledgebase Artikel Q10172 importiert

==Summary==
Maximum users for an innovaphone DHCP Server

==Applies To==
This information applies to
* IP3000
* IP800

'''FAQ:'''
For how many phones can an ip3000 be dhcp server be used

'''Answer:'''
The restriction for the amount of dhcp leases is the limitation of memory segments for VARs.

Normally a single segment has 64 kB (128 kB at the IP800). An entry has 84 Byte -> 65536/64 = 1024. Due to the fact that there aren’t only dhcp leases in the VAR segment, an amount of nearly 800 leases will be realistic.

== Related Articles ==



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

Howto:How can I be programmatically notified for connections (like phone number x is calling phone number y) for all calls in a PBX? Also about the hangup/disconnect event of the connection between those ph

2008-01-30T18:08:30Z

Gpa: gpa Knowledgebase Artikel Q10392 importiert

'''FAQ:'''
How can I be programmatically notified for connections (like phone number x is calling phone number y) for all calls in a PBX? Also about the hangup/disconnect event of the connection between those phones? Do you have an example in C++, C# or any other language? My goel is to synchronise a vid...

'''Answer:'''
You would be using the SOAP API. This is an XML based protocol between a computer and the PBX/gateway. In a standard firmware package, have a look at the "soap" folder, you will find the documentation in it. The wsdl file is on the web.

Of course you can also use TAPI, if you like to. But for a new application, TAPI is much (really: much!) more difficult to use.

== Approved Comments ==
SOAP Doc are poor in the section on how to read the call destination (outgoing) or the call source (incoming). I have the same problem and SOAP Doc does not really help.



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

Reference:Administration/PBX/Objects/Message Waiting

2007-10-24T12:18:15Z

Gpa: gpa 24.10.2007 - link under DTMF Commands added

The message waiting object (MWI) is used to store message waiting status for other endpoints.
The MWI status can be interrogated by these endpoints and is also sent actively to the endpoint if the status changes.
For H.323 endpoints H.450-7 messages are used for this purpose.
The endpoint can use this information to turn a message waiting LED on/off.

The MWI status can be set by two methods:
* Normal call to the MWI object with DTMF commands
* H.450-7 MWI-ACTIVATE/MWI-DEACTIVATE facilities

== Configuration ==

{|
|valign=top nowrap| '''Announcement URL'''
| The URL for an announcement to be played when the MWI object is called. This announcement can be used to give explanation what DTMF commands are available. If no Announcement is configured the builtin Music on Hold is played.
|-
|valign=top nowrap| '''Extern Name/Number'''
| The announcement can also be retrieved from another endpoint. If a Name or Number is configured a call is sent to this Name/Number when the MWI object is called. The configured URL is sent as User User Information (UUI) with this call, so that it can be used by the called endpoint to retrieve the announcement.
|}

== DTMF Commands ==

The following DTMF commands are available when the MWI object is called:

{|
|valign=top nowrap| '''*1*<dest>'''
| Set MWI for the endpoint <dest>
|-
|valign=top nowrap| '''*2*<dest>'''
| Clear MWI for the endpoint <dest>
|-
|valign=top nowrap| '''#'''
| Clear MWI for the calling endpoint.
|}

Alternatively (for endpoints not being able to send '*' or '#'):

{|
|valign=top nowrap| '''1<dest>'''
| Set MWI for the endpoint <dest>
|-
|valign=top nowrap| '''2<dest>'''
| Clear MWI for the endpoint <dest>
|-
|valign=top nowrap| '''3'''
| Clear MWI for the calling endpoint.
|}

The MWI state could also be cleared by Feature-Codes.

See further information under: [[Reference:Feature_Codes#Local_Clear_of_MWI]].

== Call Diversions ==

Call Diversions can be configured for the object, but are of no real use. CFB or CFNR are never executed. CFU is executed.

Reference:Administration/Diagnostics/CF

2007-08-31T15:01:13Z

Gpa: gpa - Translated into english for expensive € 29.-!!

__NOTOC__
Depending on device, this menu shows you whether a '''CF''' card is being used. Please note that the devices support the '''FAT32''' format only. To be able to use the CF card properly, it must be formatted accordingly beforehand. The card can only be formatted if it is first ''unmounted' using the umount button.
'''Note'''
The card is only really unmounted if no folders or files are being accessed any more.
If, for example, voicemail that is on the CF card is accessed,
then the block and the subsequent formatting only take effect when the voicemail is no longer being accessed.

To transfer files to the CF card, the card must be connected as a network drive. This is only possible in a ''mounted'' state. Should the CF card be unmounted, it must be mounted using the mount button.

'''Note'''
To be able to connect the CF card as a network drive, the following path must be used:
"''\\<IP address of the gateway>\DRIVE\CF0''".
User and password correspond to the user and password as configured in chapter "[[Reference:Configuration/General/Admin|Configuration/General/Admin]]".

The following buttons are available:
== Mount/Umount ==
Mounts/unmounts the CF card. If the card is not mounted, it cannot be accessed. It can however be formatted or a checkdisk can be run.

== Chkdisk ==
Checks the CF card for errors.

== Format ==
Formats the CF card in the FAT32 format.

Reference:Configuration/IP/Settings

2007-08-21T13:08:28Z

Gpa: gpa - Anpassung der Textstärke für verständlichere Verknüpfung der Erläuterung

The basic IP settings are made here.

== TOS ==

The TOS (Type of Service) byte inside the IP header is used for prioritization of packets inside the network. The device allows some packets to be marked as higher priority. The TOS values for this purpose are configured here.
{|
|valign=top nowarp=true|'''TOS Priority RTP-Data'''
|Configuration of the TOS value for media (e.g. voice) packets. The value 0x10 is used as standard. Consequently, voice data receives priority forwarding.
|-
|valign=top nowarp=true|'''TOS Priority Signaling'''
|Configuration of the TOS value for Signaling (e.g. H.323 or SIP) packets.
|}

== RTP Port Range ==

'''First UDP RTP port / numbers of port:''' This entry restricts the range of ports in which UDP RTP voice data (User Datagram Protocol Real-time Transport Protocol) is received for H.323 or SIP calls. The port range 16384 to 32767 is used as standard.

''Range calculation:'' 4 * <estimated-number-of-simultaneous-calls> but at least 128.

''Note:'' For every single VoIP connection 4 ports are allocated. One (even) RTP port, one (odd) RTCP port, one (even) T.38 port. The fourth port is not used but lost, since the next call's RTP port must be an even port again. This information applies to all kind of devices, even such devices that do not support T.38 fax (telephones).

''Restrictions:'' 128 ports are the smallest range.

== UDP NAT Port Range ==

'''First UDP NAT port / numbers of port:''' This entry restricts the range of ports that may use UDP NAT data (Network Address Translation).

== Local Networks ==

Here you can declare ip addresses or address ranges to be part of the ''local network''. 
This configuration influences the coder selection process on VOIP endpoints like telephones and physical Gateway interfaces. 
See [[Reference:Configuration/Registration/Registration]] for further information regarding coder preferences.

== Private Networks ==

Here you can declare ip addresses or address ranges to be part of the ''private network''. 
This configuration influences media negotiation in the '''Gateway''' application and the '''PBX''' application. 
If the Gateway/PBX forwards a call between private and non-private network addresses (inter-network calling) the '''Media-Relay mode''' is used. This keeps private IP addresses from being handed out to endpoints in public network which cannot send to private IP addresses. 
If the Gateway/PBX forwards a call between two private or two non-private addresses the '''Transit mode''' is used.

In '''Media-Relay mode''' RTP addresses are NOT passed through between the calling endpoint and the called endpoint. If the Gateway/PBX allocates local RTP ports and announces it's local RTP address to both endpoints. In result both endpoints send their RTP towards the Gateway/PBX from where it is relayed to the opposite endpoint.

In '''Transit mode''' both endpoints are allowed to exchange their RTP addresses and send RTP directly between each other. In this mode the media streaming is de-centralized which perfectly scales up to a very high call density.

==Related Articels==

[[Howto:What Ports are used for Signaling and Voice Traffic in SIP and H.323?]]

Reference:Administration/PBX/Objects/Boolean

2007-05-30T12:37:31Z

Gpa: External name/no adjusted

The Boolean PBX object is used to define time-dependent true or false states in the innovaphone PBX, and can be used for call forwarding or filters.

For example, the Boolean object Working hours (Mo-Fr 08:00-18:00 hrs) can be defined, which in the true state (that is, during office hours) is set to true and outside office hours is set to false. This would enable a filter to be defined that allows calls during office hours only.

In the same way, this Boolean object can be used for call forwarding. In the true state (true), it would allow call forwarding to a particular subscriber during office hours, in the false state (false) outside office hours. The current state can be switched using manual override.

The following specifications are made in the Boolean section.

==Announcement (URL)==
* '''TRUE:''' The path of the audio file to be played in the true state (true).
* '''FALSE:''' The path of the audio file to be played in the false state (false). This specification only makes sense if a call is received directly on this object.

==Announcement (URL) if manual override is active (optional)==
* '''TRUE:''' The path of the audio file to be played in the event of a manual override in the true state (true).
* '''FALSE:''' The path of the audio file to be played in the event of a manual override in the false state (false). This specification only makes sense if a call is received directly on this object.
* '''External Name/No:''' It is possible to play the announcement audio file of an external subscriber or call number instead of the local announcement.
'''Note:''' This external name/no must have a valid announcement configured.

* '''Manual Override:''' The Manual Override list box allows you to change the current state. A manual override (MO) can also be set using DTMF. For this, the call number of the Boolean object, followed directly by the relevant DTMF code simply have to be dialled. The following DTMF codes are possible:
**<Boolean object call number>01 - MO default state
**<Boolean object call number>11 - MO true state
**<Boolean object call number>10 - MO false state
For example, the Boolean object Working hours with the call number 50 in the true state would be transferred to the false state with the code 5011. It works exactly the same the other way round. If the Boolean object Working hours is in the false state, then it is transferred back to the true state with the code 5011. Note that the manual override should always be viewed in relation to the initial state.
* '''Weekday + Time Specification:''' Here, you specify the time condition for the decision true (true) or (false).

Reference:Administration/PBX/Calls

2007-05-16T12:23:22Z

Gpa:

In the '''Calls''' PBX overview page, all calls actively being made can be monitored. This is advantageous for diagnostic purposes in particular, since the existence of possible network problems, for example, is immediately visible (see Media).

== Subscriber A: ==
* '''Number:''' Display of the calling number.
* '''Name:''' Display of the calling name.
* '''Protocol:''' Display of the protocol used on the calling side.
* '''Media:''' Display of the coder used on the calling side, for example, ''G711AB(2,0,0)''. The values in brackets have the following meaning, in order:
** '''Round trip (RT)''' = Transit time of a data packet from A to B and back again.
** '''Jitter''' = Latency time (time interval from the end of an event up to the start of the response).
** '''Loss (PL)''' = Number of lost packets (packet loss).
* '''Dir:''' In the Alerting state ">" and in the Connected state ">>".

== Subscriber B: ==
* '''Number:''' Display of the called number.
* '''Name:''' Display of the called name.
* '''Protocol:''' Display of the protocol used on the called side.
* '''Media:''' Display of the coder used on the called side.
* '''State:''' Possible states: ''Alerting'', ''Calling'', ''Connected'', ''Disconnecting''.

==Related Articles==
[[Howto:How to read the call screen]]

Reference:Administration/PBX/Objects

2007-05-09T10:30:13Z

Gpa:

This page is used for the administration of PBX objects. A list of already configured objects can be displayed filtered by various criterias. New objects can be created and existing objects can be changed or deleted.

== Display of existing Objects ==
By pressing the show link, existing objects are displayed. With the filter field (the input field left to the show link) the displayed objects are limited to those matching the filter. The filter is first applyed to the 'Long Name' of the objects meaning a non case sensitive head match of the filter and the 'Long Name' is performed. If there are matching objects these are displayed.

If there are no matching objects the filter is used to match the Number of the objects including any node prefixes. This way objects of a given node with all subnodes can be displayed by entering the prefix of a node here.

The below the filter input field is a list of all PBXs in the system (at least the part of the system which is replicated to this device). By clicking on a PBX in the list only the objects which are assigned to this PBX are displayed and the groups configured on this PBX are displayed as well. By clicking on a group only the members of this group are displayed.

=== List of Objects ===
On the right side the list of objects is displayed. The most important configuration properties are displayed in this list to provide an overview. To view the full configuration of a given object it must be opened for editing by clicking the Long Name. The list can be sorted by clicking the table headers.

The Number of the objects in this list is not the number configured in the object but it is expanded with the prefixes of the nodes in which the object is configured.

Group memberships and Call Forwarding for an object are changed by clicking on the 'Groups' or 'CF*' link of the object. A '*' appended to a group displayed in this list means that the active flag of this group membership is set.
A '!' appended to a group displayed in this list means that group indications are configured for this group.

The last column are the IP addresses of registered endpoints for a given object. If the physical location of the endpoint is not the same as the PBX, the physical location is indicated by @<physical-location> added to the IP address. A '*' appended to this field means that this is an password authenticated registration.

=== New Objects ===
New objects are created by selecting the type of object in the drop down list and clicking the new link. If the list of displayed objects is limited to a PBX/Group (see above), the PBX property of the new object is preset accordingly and the group membership is added to the object.

== Object Properties ==
Depending on the type of the object different configuration parameters are available. Some configuration parameters are common for all objects.

{|
|valign=top nowrap=true|'''Long Name'''
|This name is used to identify the object in the database and for display purposes. The long name must be unique throughout the system.
|-
|valign=top nowrap=true|'''Name'''
|The name of the object. This name is used for signalling (like a call number) and must be unique throughout the system.
|-
|valign=top nowrap=true|'''Hardware ID'''
|The hardware ID is a name which can be used to register an endpoint to this object. This name is not displayed and cannot be used to call the object. Some endpoints use default names to register based on the MAC address of the endpoint, which can be configured here. This way there is no need to configure any Name/Number on the endpoint itself.
|-
|valign=top nowrap=true|'''Node'''
|The node that the object is assigned to. A Node hierachy can be configured using Node Objects. Objects which are assigned to the same node can call each other with just the number. To call an object in a different node escapes and node prefixes have to be used. See [[Howto:PBX_Locations]].
|-
|valign=top nowrap=true|'''PBX'''
|The PBX that the object is assigned to. This PBX accepts registrations for the object.
|-
|valign=top nowrap=true|'''Local'''
|Marks an object as local. Local means that it can be called from endpoints physically located at the same PBX without prefixes even if the calling endpoint is in a different node.
|-
|valign=top nowrap=true|'''Password / Retype Password'''
|If a registration password is allocated here, then it must be specified during registration, or otherwise the registration will fail.
|-
|valign=top nowrap=true|'''Filter'''
|The filter configured here restricts the numbers which may be called by a endpoint registered to this object
|-
|valign=top nowrap=true|'''Diversion Filter'''
|The filter configured here restricts the numbers which calls may be diverted to by a endpoint registered to this object
|-
|valign=top nowrap=true|'''CFNR Timeout'''
|Overides the PBX global CFNR timeout for this object
|-
|valign=top nowrap=true|'''Busy on n Call(s)'''
|Maximum number of calls made simultaneously. If, for example, the numeric value two is entered, then busy is signalled to the third and all further incoming calls. Just as only two calls can be set up parallel.
|-
|valign=top nowrap=true|'''Group Indications'''
|The group for which group indications are sent to the registered endpoints. The object must be active member in this group. The other objects (for which group indications are sent) need not to be active. To monitor other endpoints on a phone with a Partner/Pickup function key group indications are needed for the endpoints.
|}

== PBX Object Types ==
* [[/User|User]]
* [[/Boolean|Boolean]]
* [[/Call_Broadcast|Call Broadcast]]
* [[/DECT_System|DECT System]]
* [[/DTMF_Features|DTMF Features]]
* [[/Executive|Executive]]
* [[/Gateway|Gateway]]
* [[/MCast_Announce|MCast Announce]]
* [[/Message_Waiting|Message Waiting]]
* [[/Number_Map|Number Map]]
* [[/Node|Node]]
* [[/Trunk_Line|Trunk Line]]
* [[/Voicemail|Voicemail]]
* [[/Waiting_Queue|Waiting Queue]]

Reference:Administration/PBX/Objects/Trunk Line

2007-05-09T10:26:11Z

Gpa: links adjusted

The Trunk Line PBX object represents the trunk line in the innovaphone PBX. To register an ISDN trunk line with the Trunk Line PBX object, an H.323 registration with specification of the gatekeeper ID and call number simply has to be activated on the interface with connected trunk line (see also chapter "[[Reference:Administration/Gateway/Interfaces|Administration/Gateway/Interfaces]]").

The following specifications are made in the Trunk section:
* '''Loopback:''' If the call number of the exchange was dialled in incoming calls via the exchange, call forwarding can be initiated by specifying a valid H.323 name (Name) or E.164 alias (Number).
* '''Incomplete:''' If an incomplete call number was dialled in incoming calls via the exchange, call forwarding can be initiated by specifying a valid H.323 name (Name) or E.164 alias (Number).
* '''Invalid:''' If an invalid call number was dialled in incoming calls via the exchange, call forwarding can be initiated by specifying a valid H.323 name (Name) or E.164 alias (Number).
* '''Busy:''' If, in incoming calls via the exchange, a call number was dialled that is busy, call forwarding can be initiated by specifying a valid H.323 name (Name) or E.164 alias (Number).
* '''No Answer Timeout:''' If, in incoming calls via the exchange, a call number was dialled and there is no answer, call forwarding can be initiated, after the specified time has elapsed (Timeout), by specifying a valid H.323 name (Name) or E.164 alias (Number).
* '''Reroute supported:''' This check box determines wether Partial Rerouting will be performed while executing a diversion (CFU, CFNR). Please, see [[Howto:How to Configure EDSS1 Partial Rerouting|How to Configure EDSS1 Partial Rerouting]] for detailed configuration information.
* '''Set Calling = Diverting No:''' Concerns calls that arrive on the PBX via the Trunk Line PBX object and are then forwarded by CFU, CFB or CFNR (Call Forwarding Unconditional, Call Forwarding Busy or Call Forwarding No Response) again via the Trunk Line object. For example: Subscriber A calls subscriber B. Subscriber B forwards the call from subscriber A to subscriber C. The CGPN (Calling Party Number) remains unchanged for a call diversion. Merely the DGPN (Diverting Party Number) is also sent as information, so that both call numbers are visible at the diversion destination (subscriber C). For an external call diversion to the PSTN, it is not permitted to use an external CGPN (subscriber A), however. Therefore, the CGPN must be replaced by an associated call number, in this case the DGPN (subscriber B). If this check box is not enabled, the local telephone office, in such as case, will automatically replace the CGPN through "screening". If you enable this check box, the diversion call is signalled as a normal outgoing call. The CGPN is then a number that belongs to the connection (subscriber B).
* '''Outgoing Calls restricted:''' This check box allows you to suppress the display of the outgoing call number in general.
* '''Outgoing Calls CGPN:''' The call number for outgoing calls (Calling Party Number) can be manipulated in general.

Here is an example of how a trunk line can be established or simulated:
# First, the Trunk Line PBX object with the E.164 call number 0 and the H.323 name Exchange must be created.
# On a free ISDN interface (PPP, TEL, BRI or PRI), you enable the H.323 registration and allocate the name of the of the Trunk Line object (Exchange) or the call number (0), as well as the IP address of the gatekeeper on which the PBX is operated. It is also sufficient to specify the local IP address 127.0.0.1 if the gatekeeper happens to be operated on the same device. The interface must have successfully registered with the PBX object and calls to the Trunk Line PBX object must be possible. A dial tone is played at this point only with a connected ISDN trunk line. Suffix dialling digits are accepted.
# To simulate a dial tone for least cost scenarios, for example (see also the chapter entitled "[[Reference:Administration/Gateway/Interfaces|Administration/Gateway/Interface/Virtual Interface (TEST, TONE, HTTP)]]", a free VoIP interface is required, which likewise registers with the Trunk Line PBX object as the gateway (mode). The gatekeeper address is allocated as described in the previous point. The name (Exchange) or the call number (0) of the Trunk Line PBX object are also allocated in the same way (under Alias List).
# Finally, a route from the ISDN interface and from the VoIP interface to the TONE interface must be created, enabling the simulated dial tone to be played. Suffix dialling digits are accepted.

== Related Articles ==
[[Howto:How to Configure EDSS1 Partial Rerouting|How to Configure EDSS1 Partial Rerouting]]

Reference:Update Server

2007-05-09T10:16:37Z

Gpa: links adjusted

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 UP1 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.
When you discover problems that the update isn't working and the update screen in the GUI is presenting "failed 404" then check if the file name, for example "update-ip1200" does have the extension *.htm.

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 be executed not every time as soon as it is received, but once only. Assuming that a secure configuration is to be loaded onto several devices, then it is best if this is done from one device. 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 with the standard settings) called UPDATE/CHECK. The check command compares the content of <serial> with the UPDATE/CHECK variable. If both match, all further processes of the maintenance file are terminated.

If they differ, the remaining processes are executed. When the last process has been executed, the UPDATE/CHECK variable is overwritten with the content of <serial>, and the content of <final-command> is executed. The following commands are usable content for <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: Is a global variable and not a function.

=== Time command ===
Often it is preferred to perform such changes at particular times (for example, at night when no work is being done). This can be achieved with the times command:

'''mod cmd UP1 time [/allow <hours>]'''

The time command compares the current time with the content of <hours>. <hours> is a comma-separated list of specified hours, within which execution of the maintenance file is possible. If the content of <hours> with the restriction does not match, all further processes are terminated. The following hours are considered valid times, within which execution of the maintenance file makes sense.

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

With this command, execution of the maintenance file is allowed from 12:00 to 12:59 hrs and from 22:00 to 04:59 hrs. If the device does not have a time, all processes are terminated.

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

If the /initial parameter is set, no further commands are executed within the specified number of minutes <minutes>, once the device has been reset. This was implemented to avoid a firmware download and the overwriting of Flash memory during device installation.

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

With this specification, all processes of the maintenance file are suppressed within the first six minutes and within the valid times specified in the /allow parameter after every device restart. If the /initial parameter was set, new devices (or devices that were reset with the standard settings) can, after a restart, receive the maintenance file within the number of minutes specified in the /initial parameter, even if they lie outside the valid times as specified in the /allow parameter. This allows new devices to receive a current standard configuration quickly.

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

'''mod cmd UP0 prot <url> <final-command> <built-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 ireset 04-5656</nowiki>'''

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

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 
'''mod cmd UP0 boot <nowiki>http://192.168.0.10/firm/ ireset 205</nowiki>'''

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/bootip1200.bin, the UPDATE/BOOT internal variable is overwritten with 205 and, finally, the device is reset as soon as it is not being actively used.

=== bmc command ===
The boot command allows you to update the ''burst mode controller' firmware (a.k.a. ''radio-code'') and this is done in the same way as with the prot command.

'''mod cmd UP0 bmc <url> <final-command> <built-serial>'''

The command 
'''mod cmd UP0 bmc <nowiki>http://192.168.0.10/firm/ ireset 4711</nowiki>'''

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

Please note that this should work for IP600 and IP1200 and for version 5 and 6, but not for IP1500. Of course, it does only work for DECT devices anyway.

=== SCFG command ===
If the UP0 interface is being used, then the device configuration can be stored on a Web server.

'''mod cmd UP0 scfg <url>'''

This command instructs the device to upload its current configuration to the <url>. This can be achieved with the HTTP PUT command. The url must be writable. The following constants can be used in the url:

{|
! style="background-color:#DCDCDC;"| Sequence !! style="background-color:#DCDCDC;"| Replaces !! style="background-color:#DCDCDC;"| Example
|-
| #d || Current date and time || 20051010-170130
|-
| #m || MAC address of the device || 00-90-33-03-0d-f0
|-
| #h || Device hardware number || IP1200-03-0d-f0
|-
| #bN || Backup number (cycling from 1 to N) N defaults to 10 ||
|}

Note: #b is implemented in version 6.00 SR1

== 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</nowiki>
mod cmd UP0 prot <nowiki>http://192.168.0.10/configs/04-5679</nowiki> /ser 04-5679
mod cmd UP1 check ser 20040330-01
config change PHONECFG0 /coder G729A,60, /lang eng /protect
config change PHONEAPP0 /f4-10 BellOff /f4-v0 %1BE /f5-10 BellOn /f5-v0 %1BF
config write
config activate
iresetn

There is also the file update-ip3000.htm, which reads the following two lines:
mod cmd UP1 time /allow 23,0,1,2,3,4
mod cmd UP0 prot <nowiki>http://192.168.0.10/configs/04-5679</nowiki> /ser 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. The devices are configured so that they use the G729 codec with a frame size of 60ms, the language setting is English and the configuration is write-protected. Therefore, only an administrator with appropriate authorisation can change this file. In addition, two standard functions were programmed for the device.

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

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

Reference:User Interface

2007-05-09T10:13:07Z

Gpa: links adjusted

The '''user interface''' has been tested with Internet Explorer (5.x, 6.x) and with the Firefox browser. It can, however, also be used with Netscape.

The user interface of the VoIP device can be accessed with a Web browser by calling up the IP-Adresse determined beforehand.

== Structure of the user interface ==
The user interface of the VoIP deviceis divided into two areas:
* The navigation area (along the left and top edge of the screen), which consists of menu and submenu commands.
* The entry area, in which the device settings are made.
The main menus in the left area of the browser are divided into two categories:
* Configuration
* Administration
A main menu, in turn, can be split into several submenus.

{|
| rowspan="3"| [[Image:Web_interface.jpg‎]]
| valign="top"| In the '''Configuration''' category, everything that is necessary for initial operation (for example, the setting of the ETH0 & ETH1 network interfaces) is carried out.
|-
| valign="top"| In the '''Administration''' category, the settings for active operation can be made. This includes the adding of new users to the innovaphone PBX, for example.
|-
| valign="top"| Depending on which main menu entry is currently active or on which setting was made in a submenu, the structure or content of the submenu can change.
|}

== Protected areas ==
Apart from the start page, all areas of the device are password-protected. When shipped from the factory, the innovaphone VoIP device has:
* The standard user name '''admin''' and
* The standard user password '''ipxxx''' (ipxxx stands for the device type, for example, ip800, ip1200, etc.).
'''Caution'''
To raise the security of the VoIP device, the standard user and the standard password
should always be changed (see chapter entitled "[[Reference:Configuration/General/Admin|Configuration/General/Admin]]")!

== Saving the settings ==
The setting are saved in the respective submenu always using the '''OK''' button.
* Some changes to settings require a device restart to become effective. In this case, reset required is shown in the respective menu. More detailed information on restarting the device is contained in the chapter entitled "[[Reference:Administration/Reset|Administration/Reset]]".

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

Reference:Administration/Gateway/Routes

2007-05-09T10:02:45Z

Gpa: link to isdn errorcodes adjusted to new NS

The most important task of the gateway is call routing. It determines which calls are accepted and where they are switched to.

Call routing is carried out by the gateway's gatekeeper and is controlled by routes (for voice). For each call direction, a route must be defined. If a call passes several gateways, a relevant route must be defined in each one. A route defines a permitted path for a call, from the interface where the call arrives, to the interface from which the call departs. Calls from different interfaces are often handled in the same way. Therefore, calls from several ISDN interfaces (for example, TEL1 and TEL2) or from several VoIP interfaces (GW1-12), for example, can be permitted.

Call switching also often depends on the call number dialled. For this, the validity of routes for calls with particular destination numbers must be defined by means of a map entry. Each map entry defines that calls from the source interfaces specified in the route beginning with the combination of digits specified in the map entry can be connected to the destination interface defined in the route.

All defined routes are displayed row by row in the routing table. For each individual call, the routing table is searched from top to bottom for a suitable map entry. If it is not possible to switch the call to the identified interface, then the routing table is searched for the next map entry that meets the specified conditions. If a map entry was found, the current call is switched to the destination interface of the map entry defined. If no suitable map entry was found, the call is invalid and is not put through.

== From - To ==
The routing table is structured as follows:
* '''From:''' The source interface from which a call is to be accepted. It may be an ISDN interface (TEL, BRI, PRI, etc.) or a VoIP interface (GW1-12).
* '''To:''' The destination interface to which a call is to be switched. It may be an ISDN interface (TEL, BRI, PRI, etc.) or a VoIP interface (GW1-12).
* '''CGPN Maps:''' The CGPN (Calling Party Number) map is used for modifying the calling number. It allows the extension to be suppressed for outgoing calls, for example, but also the entire map entry can be made dependent on the calling number.

To create a new routing entry, you must click the Insert Route below button. A popup page opens, on which the route setting can be made.

This popup page also contains the specification of the map entries. Clicking the Add Map above/below buttons opens the same popup page and adds a map entry at the relevant place. This popup page is structured as follows:

* '''Description:''' The descriptive name for the route.
* '''Source interface:''' Here, you select the ISDN or VoIP interface that is to apply as the source for the relevant route. It is also possible to select several sources. The source interfaces available in principle are: RT, RS, TEL, BRI, PRI, PPP, TEST, TONE, HTTP, SIP and GW.
* '''Number In:''' To make the routing decision dependent on a map entry, you must enter the calling number here. If no number is specified here, the map entry is valid for all calls. There are additional variants of call number manipulation available: If a route is to apply to a particular number and all of the digits that are subsequently dialled are to be ignored, the specified call number must be followed by the "!" operator. Some devices require the "#" operator as the signalling character for the end of a call. For this, the Add # check box can be checked (see description further down in the text). With the "?" operator, it is also possible to replace a variable unknown and known number of characters by a particular one. For example, "???" replace with 1 gives, say for "1234" -> "14", or "0???" replace with 1 gives, say for "01234" -> "14", since the known digit 0 is likewise replaced. With the "." operator, a particular number of characters can be replaced. For example, "..." replace with "123" gives, say for "321" -> "123".
* '''Number Out:''' Here, you enter the route’s call number to be replaced, if desired. If the call number is to be adopted unchanged, the same call number as in Number In must be specified here. 
'''Note:''' If the calling number was manipulated, the Verify CGPN check box must not be checked, since the checking of the calling number would fail, making the map entry ineffective.
* '''Destination interface:''' Here, you select the interface that is to apply as the destination for the relevant route. The destination interfaces available in principle are: RT, RS, TEL, BRI, PRI, PPP, TEST, TONE, HTTP, SIP, GW, MAP and DISC.
* '''Name Out:''' If the H.323 call name is to be changed, the new call name can be entered here.
* '''Cause (DISC):''' If the DISC destination interface was selected, a so-called disconnection cause (see Appendix C "[[Reference:ISDN Errorcodes|ISDN Errorcodes]]") can be additionally specified, to obtain appropriate output on the terminal.

For every route definition, advanced settings can be made:
* '''Add UUI:''' If manufacturer-specific data is to be transmitted in the signalling channel, for example, the URL for an announcement, then this URL (<nowiki>http://192.168.0.1/webdav</nowiki>) can be specified here.
* '''Final Route:''' A checked check box simulates the end of the routes. If further routes are to follow, they are ignored.
* '''Final Map:''' A checked check box simulates the end of the map entries. If further map entries are available, all further map entries are ignored.
* '''Exclude from Auto CGPN:''' If the Automatic CGPN Mapping check box was checked in chapter "[[Reference:Administration/Gateway/General|Administration/Gateway/General]]", the relevant route can be excluded from the automatic correction of all calling numbers by checking this check box.
* '''Verify CGPN:''' The routing decision is normally made on the basis of the routes themselves and the map entries defined in the routes. With a checked check box, the routing decision is made on the basis of the CGPN maps. This means that first the calling number is checked and, only if the calling number matches, is the routing table further processed and call switching, for example, takes place. Since this only applies to the verification and restriction of particular numbers, no manipulation of the call number takes place here. In this way, access to a chargeable trunk line, for example, can be restricted to certain extensions (selective direct outward dialling). If the Automatic CGPN Mapping check box was checked in chapter "[[Reference:Administration/Gateway/General|Administration/Gateway/General]]", the check is applied to the number already corrected.
* '''Interworking (QSIG):''' A checked check box enables translation of H.323 or SIP to QSIG. Here, no translation from QSIG to H.323 or SIP takes place, rather, the transmission is transparent (is used where PBXs of the same kind are linked via VoIP).
* '''Force Enblock:''' A checked check box enforces enbloc dialling. This means that if a map entry applies, all subsequently dialled digits are collected until more than four seconds have passed since the last digit was dialled.
* '''Add #:''' A checked check box transmits the hash character (#) to mark the end of a call number. This is only required for terminals that do not recognise the end of the call number (such as Cisco terminals, for example).
* '''Disable Echo Canceller:''' A checked check box suppresses echo cancellation for the relevant map entry. This is normally only necessary if the connection used as the voice connection is not to perform echo cancellation, as is the case with modems, for example.
* '''Call Counter max:''' If there is insufficient bandwidth available, a name can be entered in the Call Counter field, and the maximum number of calls permitted for the relevant route can be entered in the max field.

Clicking the name of a route (for example, TEL1:exchange) filters the display of the routes by the set interface. Clicking the name of the route a second time again shows the routes that are not associated. If, for example, several routes have been created for the TEL1 interface, then clicking one of the TEL1 interfaces hides all other routes that do not have TEL1 selected as the source or destination interface.

The adjacent arrow button (-->) can be used to edit routes.

== CGPN Maps ==
It is also often necessary to define routes depending on the calling number. Just as maps are added to routes, so-called CGPN maps must be added to the maps for this purpose. This not only allows calling numbers to be manipulated in order to suppress the extension for outgoing calls, for example, but also the entire map to be made dependent on the calling number.
The arrow button (-->) in the CGPN Maps column can be used to define and edit such maps.
* '''Number In:''' The calling number. The CGPN map is valid if the inbound E.164 call number matches the call number or dial prefix set here.
* '''Name In:''' The calling name. The CGPN map is valid if the inbound H.323 call name matches the name set here.
* '''Number Out:''' Here, you enter the call number or dial prefix to be replaced for the switching.

Reference:Administration/Gateway/General

2007-05-08T13:34:56Z

Gpa:

== General Gateway Settings ==
{|
|valign="top" nowrap="true"|'''Gatekeeper ID'''
|The Gatekeeper Identifier. This is used with VOIP interfaces configured as "Gatekeeper/Registrar" as Gatekeeper Identifier (H.323) or Registrar Name (SIP). If multiple Gatekeepers are installed in a network this can be used to find the right gatekeeper using gatekeeper discovery. If a PBX is enabled on the same system a different Gatekeeper Identifier must be used for Gateway and PBX.
|-
|valign="top" nowrap="true"|'''Call Logging'''
|A checked check box enables the output of syslog information in respect of the calls made via the gateway.
|-
|valign="top" nowrap="true"|'''Route Logging'''
|A checked check box enables the output of syslog information in respect of the used voice routes of the gateway.
|-
|valign="top" nowrap="true"|'''Billing CDRs only'''
|If enabled for each call only a single record at the end of the call is send as CDR. This record contains all information needed for billing purposes.
|}

== Feature Codes ==
{{Feature-Codes}}

== Licenses ==
This table displays the installed licenses and the current use of these licenses.
{|
|valign="top" nowrap="true"|'''Gateway'''
|Valid only if this is an OEM version of the gateway, which by default does not have "Gateway" capabilities. If there are no Gateway capabilities the Interfaces can only be used for a local PBX.
|-
|valign="top" nowrap="true"|'''Gatekeeper6'''
|Gatekeeper licences. Allows VOIP Interfaces of type "Gatekeeper /Registrar" to be configured.
|-
|valign="top" nowrap="true"|'''BRIs'''
|Basic Rate ISDN interfaces. The available licenses are used for the interfaces in the sequence the interfaces are displayed. To use other interfaces it is possible to disable interfaces
|-
|valign="top" nowrap="true"|'''PRIs'''
|Primary Rate ISDN interfaces. The available licenses are used for the interfaces in the sequence the interfaces are displayed. To use other interfaces it is possible to disable interfaces
|-
|valign="top" nowrap="true"|'''Channels'''
|DSP channels.
|-
|valign="top" nowrap="true"|'''ABs'''
|Analog interfaces.
|}

Howto:DHSG headset specification

2007-05-07T13:46:55Z

Gpa: attachement changed

here is the technical specification of the DHSG headset interface, also used in the IP230. Please note that DHSG is a de factor standard, not a proprietary definition by innovaphone. this specification only exists in German, unfortunately.

==Article Attachements==
[[Media:TR-DSHG.zip]]



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

Reference:Configuration/DECT/Features

2007-05-07T11:09:22Z

Gpa: template name changed

Template:CGPN-CDPN Mappings

2007-05-07T11:08:06Z

Gpa: Category templates added

For every interface, it is possible to store so-called '''CGPN In, CDPN In, CGPN Out and CDPN Out mappings''' (Calling Party Number In, Called Party Number In, Calling Party Number Out, Called Party Number Out), enabling call numbers and call number formats to be adjusted for incoming and outgoing calls. The call number formats are as follows:

{| border="0"
! Unknown:
| Unspecified. Number called in outgoing calls.
| u
|
|-
! Subscriber:
| Call number in local network. Number called in incoming calls.
| s
|
|-
! National:
| Call number with area code. Calling number from home country.
| n
| 0
|-
! International:
| Call number with country code and area code. Calling number from abroad.
| i
| 00
|-
! Abbreviated:
| Unusual.
| a
|
|-
! Network-specific:
| Unusual.
| x
|
|}

Clicking the link ''+'' or a mapping already created (for example, n->0) opens a popup page, on which the setting for the CGPN In, CDPN In, CGPN Out and CDPN Out mappings can be made:

* '''CGPN In:''' Is used to process the calling number of incoming calls.
* '''CDPN In:''' Is used to process the called number of incoming calls.
* '''CGPN Out:''' Is used to process the calling number of outgoing calls.
* '''CDPN Out:''' Is used to process the called number of outgoing calls.

Each mapping can be specified for a particular call number type:

* '''Unknown:''' The mapping applies to unknown, external calls.
* '''ISDN:''' The mapping applies to external calls.
* '''Private:''' The mapping applies to internal calls.

[[Category:Templates]]

Reference:Administration/Gateway/Interfaces

2007-05-07T11:06:58Z

Gpa: template name changed

The display of the gateway’s configurable '''interfaces''' is organised in columns:

* '''Interface:''' The name of the interface. Clicking this name opens a popup page, on which all settings can be made. The settings are described in more detail in the following chapter "[[#CGPN.2FCDPN_Mappings|Administration/Gateway/Interfaces/Interface (ISDN & virtual interfaces)]]".
* '''CGPN In, CDPN In, CGPN Out, CDPN Out:''' Precise details on CGPN In, CDPN In, CGPN Out and CDPN Out mappings are contained in the chapter entitled "[[#CGPN.2FCDPN_Mappings|Administration/Gateway/Interfaces/CGPN-CDPN Mappings]]" further down in the text.
* '''State:''' The current state of the interface at physical and at protocol level. Possible states are: ''Up'', ''Down''.
* '''Registration:''' If a terminal has successfully registered with an ISDN, SIP or virtual interface, then this is indicated in this column through specification of the IP address <Name of the VoIP interface:Call number:IP address>.

== Interface (ISDN, SIP & virtual interfaces) ==
Clicking the name of an interface in the Interface column opens a popup page, on which the interfaces can be individually configured. Like the PBX objects, this popup page also contains standard entry fields that occur, more or less, in all interfaces. These standard fields are:

* '''Name:''' The descriptive name of the interface.
* '''Disable:''' A checked check box disables the relevant interface.
* '''Tones:''' The standard calling tone for the relevant interface is set with the Tones list box.
* '''Interface Maps:''' The interface can be configured as a point-to-point connection (Point-to-Point), as a point-to-multipoint connection (Point-to-Multipoint) or manually (Manual) using CGPN/CDPN maps.
See description further down in the text.
* '''Registration:''' With the Registration list box, an H.323 registration or a SIP registration can be initiated for ISDN interfaces. The routes to be handled as incoming and outgoing calls on the relevant interface are automatically created here (see "[[Reference:Administration/Gateway/Routes|Administration/Gateway/Routes]]").

=== ISDN interfaces (PPP, TEL1-4, BRI1-4, PRI1-4) ===
After selection of an '''interface map''', the relevant section is displayed. If Point-to-Point is selected, the Interface Maps Point-to-Point section is displayed:

* '''Area Code:''' The international code (for example, 49).
* '''Subscriber Number:''' The local network number (for example, 7031).
* '''National Prefix:''' The national prefix (for example, 0).
* '''International Prefix:''' The international prefix (for example, 00).

If Trunk Point-to-Multipoint is selected, the Interface Maps Point-to-Multipoint section is displayed:
* '''MSN1-3 / Ext.:''' For every ISDN basic access, several call numbers can be configured. The innovaphone gateways support up to three multiple subscriber numbers (MSN1-3), followed by the extension (Ext.), which represents the extension to which the MSN is to be mapped.
* '''National Prefix:''' The national prefix (for example, 0).
* '''International Prefix:''' The international prefix (for example, 00).

==== Coder Preferences section: ====
After selection of a registration method, the '''Coder Preferences''' section is displayed together with the relevant Registration section.

The standard entry fields in the Coder Preferences section are:

* '''Model:''' The Model list box allows you to select the coder to be used. The coders available for selection are: ''G711A, G711u, G723-53, G729A, G726-32 and XPARENT''. If the remote VoIP device does not support the set coder, a commonly supported coder is used, unless the Exclusive check box was enabled.
* '''Frame:''' Determines the packet size used in transmitting voice data (in ms). Larger packets cause a greater delay in voice data transmission, but cause less load on the network, since the overhead involved in transporting the packets in the network is lower. The higher the packet size used, the lower the bandwidth effectively used.

'''Encoding method | Packet size | Bandwidth'''
---------------------------------------------
G.711 | 30ms | 77kb
G.711 | 90ms | 68kb
---------------------------------------------
G.729 | 30ms | 21kb
G.729 | 90ms | 12kb

* '''Exclusive:''' A checked check box enforces the set encoding (Model), regardless of whether it is supported by the remote VoIP device.
* '''SC:''' A checked check box enables SC (Silence Compression). With SC, no data is transmitted during pauses in the conversation. This also allows bandwidth to be saved without quality loss.
* '''Enable T.38:''' A checked check box enables the T.38 Fax-over-IP protocol. If a fax machine was connected to the relevant interface, then this check box must be enabled; otherwise, fax transmissions are not handled.
* '''Enable PCM:''' A checked check box enables the PCM switch (Pulse Code Manipulation). Calls from one interface to another interface are then handled directly over the ISDN PCM bus, which in turn saves DSP channels. This entry field is optional and is displayed only in particular devices.

'''Registration section:'''

All non-virtual interfaces additionally have the '''Registration''' section after selection of the registration method.

==== H.323 Registration section ====
The entry fields for an '''H.323 registration''' are:
* '''Gatekeeper Address (primary):''' The primary gatekeeper IP address at which the interface is to register. If the primary gatekeeper is located on the same device, the local IP address 127.0.0.1 can also be entered here.
* '''Gatekeeper Address (secondary):''' The secondary gatekeeper IP address at which the interface is to register, if registration with the primary gatekeeper fails. If the secondary gatekeeper is located on the same device, the local IP address 127.0.0.1 can likewise be entered here.
* '''Gatekeeper ID:''' It is also sufficient to specify only the Gatekeeper ID (see also the chapter entitled "[[Reference:Administration/Gateway/General|Administration/Gateway/General]]").
* '''Name:''' The unique, descriptive H.323 name of the interface or registration.
* '''Number:''' The unique E.164 call number of the interface or registration.
* '''Password / Retype:''' The security of the registration can be raised by specifying a password (Password). The password must be confirmed (Retype).
* '''Supplementary Services (with Feature Codes):''' A checked check box enables the use of additional features (Feature Codes). See description in the chapter entitled "[[Reference:Administration/Gateway/General|Administration/Gateway/General]]".
* '''Dynamic Group:''' A dynamic group can be added to the H.323 registration. Groups can be configured as static, dynamic-in or dynamic-out. For members of static groups, calls are always signalled. It works differently for members of dynamic groups, which register with or unregister from a group dynamically using a function key (Join Group). The difference between dynamic-in and dynamic-out lies in whether the object is to be contained in the relevant group as standard (in) or not (out).
See also description in the chapter entitled "[[Reference:Administration/PBX/Objects|Administration/PBX/Objects]]".
* '''Direct Dial:''' Using Direct Dial, a call setup to the specified call number is initiated as soon as the handset is picked up. A conceivable scenario would be a lift emergency telephone that is connected with the security control room, for example.
* '''Locked White List:''' Here, you can specify a comma-separated list of call numbers that may also be dialled in the case of a locked telephone (for example, emergency services numbers, like 110, 911).

==== SIP Registration section ====
The entry fields for a '''SIP registration''' are:
* '''Server Address (primary):''' The IP address or the proxy server address of the SIP provider (for example sipgate.de, 217.10.79.9), to where the SIP messages (for example, register) are to be sent.
* '''Server Address (secondary):''' If the SIP provider has an alternative IP address or proxy server, then it can be entered here. In the event of failure of the primary server (for example, when maintenance is being carried out), the registration is then retained.
* '''STUN Server:''' The STUN server name or IP address must be configured if the telephone uses a private IP address, but the SIP server is accessible under a public IP address. The value is given by the SIP provider or administrator (for example, stun.xten.com or 64.69.76.23). You can choose any STUN server; it does not necessarily have to correspond to the one of the SIP provider.
* '''ID @:''' Here, you enter the user ID followed by the SIP provider domain name (for example, 8111111e0@sipgate.de).
* '''Display Name:''' The name you enter here, which corresponds to the part in front of the @ of the URI, is required for the registration if the number (Account) was not specified (for example, 8111111e0).
* '''Account:''' Likewise in this protocol, a call number is required for the registration, which corresponds to the part in front of the @ of the URI (for example, 8111111e0).
* '''Password / Retype:''' The password (Password) of the SIP Account must be specified and confirmed (Retype).
* '''Supplementary Services (with Feature Codes):''' See entry fields for an '''H.323 registration'''.
* '''Dynamic Group:''' See entry fields for an '''H.323 registration'''.
* '''Direct Dial:''' See entry fields for an '''H.323 registration'''.
* '''Locked White List:''' See entry fields for an '''H.323 registration'''.

=== SIP interfaces (SIP1-4) ===
In addition to the ISDN interfaces (PPP, TEL1-4, BRI1-4, PRI1-4) and virtual interfaces (TEST, TONE, HTTP), there are also four SIP interfaces (SIP1-4), which can be used to obtain a trunk line from a SIP provider, for example. For a description of the entry fields, please refer to the description of the SIP registration above. There are, however, three further entry fields:

* '''Name:''' A descriptive name for the interface.
* '''Disable:''' Disables the relevant interface.
* '''Registration:''' Corresponds to the Registration entry field of the ISDN interfaces. After selection of H.323, the Registration for H.323 section is displayed, enabling registration of a SIP Account with a local PBX (for example, innovaphone PBX). After selection of SIP, the Registration for SIP section is displayed, enabling in turn registration with a local SIP PBX (for example, innovaphone PBX).

To obtain a trunk line from a SIP provider, you must proceed as follows:

# Open one of the four SIP interfaces.
# Enter SIP Account data (ID, STUN server, Account, password).
# Under Registrations, link the SIP registration via H.323 to a PBX object of the Trunk type created beforehand (specification of the GK ID or GK address and the H.323 name or E.164 call number is sufficient).
# Confirm with OK.

A successful registration is displayed in the overview page Administration/Gateway/Interfaces as follows:
{| border=1
! style="background:#DCDCDC;"| State (IP of the SIP provider) !! style="background:#DCDCDC;"| Alias (PBX user object) !! style="background:#DCDCDC;"| Registration (IP of the PBX)
|- valign="top" align="center"
| For example, 217.10.79.9 (sipgate.de)
| H.323 name:E.164 no. SIPTrunk:8
| --> 127.0.0.1
|}

In the example above, the trunk line of the SIP carrier sipgate.de is picked up using the Trunk PBX object with the name SIPTrunk and the call number 8. The dialling of the call number 807031730090 therefore initiates a call at innovaphone AG via the configured SIP carrier.

=== Virtual interfaces (TEST, TONE, HTTP) ===
The non-configurable, internal interface TEST is only usable as the destination for a call. If a call is received on this interface, the music on hold contained in the non-volatile memory is played. Incoming calls must be in G.729A or G.723 format; other formats are not supported. Suffix dialling digits are ignored.
The internal interface TONE is only usable as the destination for a call. If a call is received on this interface, it is connected and the configured dial tone (Tones) is played. This happens particularly with least-cost-routing scenarios, where the call can only be switched once some of the dialled digits have been analysed. In the meantime, the dial tone is played via the TONE interface. Suffix dialling digits are ignored. The TONE interface can process several calls.
The non-configurable, internal interface HTTP is only usable as the destination for a call. If a call is received on this interface, music on hold, an announcement or some other spoken information is played from a Web server. The configuration only makes sense in combination with the innovaphone PBX.

== CGPN/CDPN Mappings ==
{{CGPN-CDPN_Mappings}}

Template:CGPN-CDPN Mappings

2007-05-07T11:06:20Z

Gpa: Template:Tpl cgpn-cdpn mappings moved to Template:CGPN-CDPN Mappings: New template name

File:Unknown-Numbering.png

2007-05-03T11:30:45Z

Gpa: category added

[[Category:Images]]

File:Unknown-Numbering.png

2007-05-03T11:30:25Z

Gpa:

Howto:How to change or deactivate the SoftwarePhone hotkey ALT ESC?

2007-05-02T17:47:50Z

Gpa: Q10283 - HOWTO: How to change or deactivate the SoftwarePhone hotkey ALT+ESC? added

This short document explains how to change or deactivate the SoftwarePhone '''hotkey ALT+ESC'''.

==Applies To==
This information applies to

* SoftwarePhone, V5.01

build 04-5667 and later.

==More Information==
===Configuration===
You can deactivate the '''hotkey''' by typing 0 in ''HKEY_CURRENT_USER\Software\innovaphone\SoftwarePhone\main\HOTKEY''

If you are typing another key you can enforce another combination. The standard hotkey is '''ALT+ESC''' ('''''0001001b'''''). The first four digits are regarding to the first button ('''ALT''') and the second four digits are regarding to the combining button ('''ESC'''). So the hotkey '''CTRL+SPACE''' results '''''00020020'''''.



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

Howto:Authentication in the SOAP API interface

2007-05-02T17:41:07Z

Gpa: Q10524 - HOWTO: Authentication in the SOAP interface added

The authentication/user scheme used in the PBX’s SOAP API is sometimes confusing. Here is how it works.

==Applies To==
This information applies to

* all PBX platforms

==More Information==
===Problem Details===
In the PBX’s SOAP API user model, there are 3 levels of authorization.
# the basic access, controlled on the HTTP level
# the “Initialize” level
# the “UserInitialize” level

To execute any SOAP function, you must be authenticated to the PBX. This requires of course a user name and a password. There are three options for this:
# use the gateways admin user name and its password. This will give you full access to the SOAP level.
# use the user name “admin” along with the PBX password. This will give you full access to the SOAP level too.
# use the alias (aka short name) of just any PBX user that has a password defined along with this password. This will give access limited to this user.

Please note that this username and password pair is not sent as an argument to any SOAP function. Instead, it is passed on the underlying HTTP level to the PBX. The exact syntax to do that thus varies greatly depending on the SOAP platform you use. In many platforms, this user/password pair is referred to as “credentials”.

Some of the SOAP functions (such as Initialize and UserInitialize) require a user name as an argument. If so, then use the users cn as the user name. This implies that for calling a SOAP function that requires a user name argument, there must be a corresponding user object in the PBX defined. You can neither use the predefined name “admin” in this context nor the gateway admin account name defined for the gateway.

SOAP functions never have a password within their arguments.

Please note that some SOAP platform do not support HTTP digest authentication. They will be using basic authentication instead. If you implement based on such a platform, you need to enabled basic authentication in the PBX configuration, as it normally is considered unsafe and thus disabled. If you need to enable this thus depends on the SOAP application platform your applications are based on.



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

Howto:SIPTronic ST-100 H.323 IP Phone

2007-05-02T17:37:45Z

Gpa:

[[Image:Template-COMPAT_01.gif|right]]

==Product name==
SIPTronic ST-100 H.323 IP Phone

==Category==
H.323 IP Phone

==Functions==
* Basic Call functionality.
* For details please look at the attached test report.

==Version==
1.42.028 H.323

==Vendor==
SIPTronic

==Article Attachments==
[[Media:Compatibility-Report-Siptronic_ST-100.pdf]]

==Approved Comments..==
Very good report - very detailed and it helps very much to clarify in which situations this phone can be used, and when not. Can we get the same report for the IP100?



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

Howto:SIPTronic ST-100 H.323 IP Phone

2007-05-02T17:36:17Z

Gpa: Q10285 - COMPAT: SIPTronic ST-100 H.323 IP Phone added

File:Compatibility-Report-Siptronic ST-100.pdf

2007-05-02T17:35:01Z

Gpa:

Howto:The called party is hearing sounds coming generated by windows applications (e.g. incoming email)?

2007-05-02T17:11:40Z

Gpa:

This short document explains what to do when the called party is hearing sounds coming generated by windows applications (e.g. incoming email).

==Applies To==
This information applies to

* SoftwarePhone, V5.01

build 04-5667 and later.

==More Information==
===Configuration===
This may occur with headset or onboard soundcards with a rich set of options.

Go to '''Start > Control Panel > Sounds and Multimedia > Audio Card >''' choose the sound device used '''>''' click '''Volume''' and mute the wave slide.

==Approved Comments...==
This is also very commen with USB headsets. The ones I've tryed has always generated "computer" sound for the called party and yourself. /Håkan NaB Communication



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