innovaphone wiki - User contributions [en]

Howto:Priority calls

2022-01-10T11:08:04Z

Ole: /* Known Problems */

{{Template:3rd Party Input}}
In the scenario there are one or several extensions that always have priority when calling to other users.

This is a typical ship scenario where calls from Bridge always have highest priority. If the called party is busy, his call will be put on hold until the call from Bridge is finished.

Also some other locations have priority, example calls from Engine room and Engine Control Room to Bridge. To create this function, look to [[Howto:Multiple_Emergency_Calls]]

Here the request in detail:

*The priority calls must have a priority over eventual other existing calls.

*Priority calls can be set up as ordinary calls or as announcement calls.

*If the called extension is busy the far party must go automatically in a hold status and should not participate in the emergency conversation.

*At the end of the emergency call the previous caller should be connected again if the called user like that (and in the meantime the call has not dropped).

*If a priority outgoing call (from Bridge) is up and a second incoming priority call (from Engine to Bridge) is done, the last call signals as “call waiting”.

*If several priority calls (from Engine and Engine Control Room to Bridge) is dialing, these calls have to be connected to the same conference call.

*The feature should work on busy and idle user, the caller has to dial always the same number.

Here how it works.

==Applies To==
This information applies to

Tested with version 13 (should work from version 10, not tested)



==More Information==

===Announcement Calls===
Create a DTMF object and activate the feature Announcement call. Example: #$(3). It means that if you dial # followed by internal extension number, in our example three digits, the call is set up as an announcement call.
For all users that shall receive announcement calls, set Phone Preferences (in template, user or phone) to Announcement Calls, Incoming: Micro On.
For all users that shall send announcement calls, set Phone Preferences (in template, user or phone) to Announcement Calls, Outgoing: Allow.

If such announcement calls not are allowed from all users, create a filter under PBX-Config-Filter, and set the announcement prefix (ex #) to Not OK. Activate this call filter for template or users.

Note that such announcement calls work only for innovaphone devices, not for DECT handsets or other 3rd party devices.

===Priority Calls===
When example the Bridge calls a user, and this is busy, we want to force this as an announcement call with high priority.
For all users that have to receive priority calls, set Call Forward Busy:
Call Forward Busy to the users own extension number with announcement prefix. Only for users that are allowed to make such calls.

Example for user 303: CFB to number #303, Only from name “Bridge”.

To get it working without action from the called party, we have to set how the phone shall react on busy.

For all users that shall receive priority calls, set Phone Preferences (in template, user or phone) to Call Waiting: Disabled.

Note that such priority calls work only for innovaphone devices, not for DECT handsets or other 3rd party devices.
For DECT devices, the priority call will be signalled as a Call Waiting, and the user has to accept it.
For third-party devices, in some cases it can be solved with an automation script on the third party device. If a priority call is received, the actual call is cancelled and the priority party is called back. To get this call-back to work, the third party user object has to be CFB to a BC Conference object with the user object as member and the priority user (ex Bridge) as a member. See [[Howto:Multiple_Emergency_Calls]]. The priority user (ex Bridge) must accept call waiting. See also the next section.

===Multiple Priority Calls===
In our example, the Bridge has highest priority for outgoing calls, but has also to receive priority calls from Engine and Engine Control Room. So, the bridge must accept call waiting. But when call waiting is activated, CFB is not working.
So in additional to config for [[Howto:Multiple_Emergency_Calls]], you have to set a Call Forward Unconditional on the Bridge object.
Call Forward Busy to the users own extension number with BC Conference object number. Only for users that are allowed to make such calls.

Example for user 601 Bridge: CFU to number *9601, Only from name “Engine” and “Engine Control Room”.

[[Image:Priority_Calls_from_Bridge.png]]

===Known Problems===
Dect and non-innovaphone 3rd party devices don’t support announcement calls.

Also the innovaphone analogue gateways don't support announcement calls.

== Related Articles ==
* [[Howto:Multiple_Emergency_Calls]]
* [[Reference13r1:Concept_Soft_Conference]]

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

Howto:Priority calls

2022-01-10T11:07:49Z

Ole: /* Known Problems */

{{Template:3rd Party Input}}
In the scenario there are one or several extensions that always have priority when calling to other users.

This is a typical ship scenario where calls from Bridge always have highest priority. If the called party is busy, his call will be put on hold until the call from Bridge is finished.

Also some other locations have priority, example calls from Engine room and Engine Control Room to Bridge. To create this function, look to [[Howto:Multiple_Emergency_Calls]]

Here the request in detail:

*The priority calls must have a priority over eventual other existing calls.

*Priority calls can be set up as ordinary calls or as announcement calls.

*If the called extension is busy the far party must go automatically in a hold status and should not participate in the emergency conversation.

*At the end of the emergency call the previous caller should be connected again if the called user like that (and in the meantime the call has not dropped).

*If a priority outgoing call (from Bridge) is up and a second incoming priority call (from Engine to Bridge) is done, the last call signals as “call waiting”.

*If several priority calls (from Engine and Engine Control Room to Bridge) is dialing, these calls have to be connected to the same conference call.

*The feature should work on busy and idle user, the caller has to dial always the same number.

Here how it works.

==Applies To==
This information applies to

Tested with version 13 (should work from version 10, not tested)



==More Information==

===Announcement Calls===
Create a DTMF object and activate the feature Announcement call. Example: #$(3). It means that if you dial # followed by internal extension number, in our example three digits, the call is set up as an announcement call.
For all users that shall receive announcement calls, set Phone Preferences (in template, user or phone) to Announcement Calls, Incoming: Micro On.
For all users that shall send announcement calls, set Phone Preferences (in template, user or phone) to Announcement Calls, Outgoing: Allow.

If such announcement calls not are allowed from all users, create a filter under PBX-Config-Filter, and set the announcement prefix (ex #) to Not OK. Activate this call filter for template or users.

Note that such announcement calls work only for innovaphone devices, not for DECT handsets or other 3rd party devices.

===Priority Calls===
When example the Bridge calls a user, and this is busy, we want to force this as an announcement call with high priority.
For all users that have to receive priority calls, set Call Forward Busy:
Call Forward Busy to the users own extension number with announcement prefix. Only for users that are allowed to make such calls.

Example for user 303: CFB to number #303, Only from name “Bridge”.

To get it working without action from the called party, we have to set how the phone shall react on busy.

For all users that shall receive priority calls, set Phone Preferences (in template, user or phone) to Call Waiting: Disabled.

Note that such priority calls work only for innovaphone devices, not for DECT handsets or other 3rd party devices.
For DECT devices, the priority call will be signalled as a Call Waiting, and the user has to accept it.
For third-party devices, in some cases it can be solved with an automation script on the third party device. If a priority call is received, the actual call is cancelled and the priority party is called back. To get this call-back to work, the third party user object has to be CFB to a BC Conference object with the user object as member and the priority user (ex Bridge) as a member. See [[Howto:Multiple_Emergency_Calls]]. The priority user (ex Bridge) must accept call waiting. See also the next section.

===Multiple Priority Calls===
In our example, the Bridge has highest priority for outgoing calls, but has also to receive priority calls from Engine and Engine Control Room. So, the bridge must accept call waiting. But when call waiting is activated, CFB is not working.
So in additional to config for [[Howto:Multiple_Emergency_Calls]], you have to set a Call Forward Unconditional on the Bridge object.
Call Forward Busy to the users own extension number with BC Conference object number. Only for users that are allowed to make such calls.

Example for user 601 Bridge: CFU to number *9601, Only from name “Engine” and “Engine Control Room”.

[[Image:Priority_Calls_from_Bridge.png]]

===Known Problems===
Dect and non-innovaphone 3rd party devices don’t support announcement calls.
Also the innovaphone analogue gateways don't support announcement calls.

== Related Articles ==
* [[Howto:Multiple_Emergency_Calls]]
* [[Reference13r1:Concept_Soft_Conference]]

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

Howto:Priority calls

2020-09-01T15:38:52Z

Ole: New howto article

In the scenario there are one or several extensions that always have priority when calling to other users.

This is a typical ship scenario where calls from Bridge always have highest priority. If the called party is busy, his call will be put on hold until the call from Bridge is finished.

Also some other locations have priority, example calls from Engine room and Engine Control Room to Bridge. To create this function, look to [[Howto:Multiple_Emergency_Calls]]

Here the request in detail:

*The priority calls must have a priority over eventual other existing calls.

*Priority calls can be set up as ordinary calls or as announcement calls.

*If the called extension is busy the far party must go automatically in a hold status and should not participate to the emergency conversation.

*At the end of the emergency call the previous caller should be connected again if the called user like that (and in the meantime the call has not dropped).

*If an priority outgoing call (from Bridge) is up and a second incoming priority call (from Engine to Bridge) is done , the last call signals as “call waiting”.

*If several priority calls (from Engine and Engine Control Room to Bridge) is dialing, these calls have to be connected to the same conference call.

*The feature should work on busy and idle user, the caller has to dial always the same number.

Here how it works.

==Applies To==
This information applies to

Tested with version 13 ((should work from version 10, not tested)



==More Information==

===Announcement Calls===
Create a DTMF object and activate the feature Announcement call. Example: #$(3). It means that if you dial # followed by internal extension number, in our example three digits, the call is set up as an announcement call.
For all users that shall receive announcement calls, set Phone Preferences (in template, user or phone) to Announcement Calls, Incoming: Micro On.
For all users that shall send announcement calls, set Phone Preferences (in template, user or phone) to Announcement Calls, Outgoing: Allow.

If such announcement calls not are allowed from all users, create a filter under PBX-Config-Filter, and set the announcement prefix (ex #) to Not OK. Activate this call filter for template or users.

Note that such announcement calls work only for innovaphone devices, not for dect handsets or other 3rd party devices.

===Priority Calls===
When example the Bridge calls a user, and this is busy, we want to force this as an announcement call with high priority.
For all users that have to receive priority calls, set Call Forward Busy:
Call Forward Busy to the users own extension number with announcement prefix. Only for users that are allowed to make such calls.

Example for user 303: CFB to number #303, Only from name “Bridge”.

To get it working without action from the called party, we have to set how the phone shall react on busy.

For all users that shall receive priority calls, set Phone Preferences (in template, user or phone) to Call Waiting: Disabled.

Note that such priority calls work only for innovaphone devices, not for dect handsets or other 3rd party devices.
For dect devices, the priority call will be signalled as a Call Waiting, and the user has to accept it.
For third party devices, in some cases it can be solved with an automation script on the third party device. If a priority call is received, the actual call is cancelled and the priority party is called back. To get this call-back to work, the third party user object has to be CFB to a BC Conference object with the user object as member and the priority user (ex Bridge) as a member. See [[Howto:Multiple_Emergency_Calls]]. The priority user (ex Bridge) must accept call waiting. See also next section.

===Multiple Priority Calls===
In our example, the Bridge has highest priority for outgoing calls, but has also to receive priority calls from Engine and Engine Control Room. So, the bridge must accept call waiting. But when call waiting is activated, CFB is not working.
So in additional to config for [[Howto:Multiple_Emergency_Calls]], you have to set a Call Forward Unconditional on the Bridge object.
Call Forward Busy to the users own extension number with BC Conference objekct number. Only for users that are allowed to make such calls.

Example for user 601 Bridge: CFU to number *9601, Only from name “Engine” and “Engine Control Room”.

[[Image:Priority_Calls_from_Bridge.png]]

===Known Problems===
Dect and non innovaphone 3rd party devices don’t support announcement calls.

== Related Articles ==
[[Howto:Multiple_Emergency_Calls]]
[[Reference13r1:Concept_Soft_Conference]]

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

File:Priority Calls from Bridge.png

2020-09-01T15:38:16Z

Ole:

Howto:How to Reset IPXXX

2019-09-17T14:32:21Z

Ole: /* More Information */ Added IP101 and IP102 to table

==Summary==
Different Reset Options of IPXXX

==Applies To==
This information applies to

* All innovaphone products with the latest boot code.


==More Information==
Different options resetting innovaphone devices.

* bringing to Factory default
* bringing to TFTP mode for GWLoad
* clearing config
* explaining the LED behavior

Additional Information for the following table, TFTP-Mode or TFTP-Mode + FACTORY RESET for the phones IP110, IP150, IP200, IP202, IP230, IP240

Seperating the phone from the power, press the Key/Button, keep on pressing the Key/Button, plug in the PSU or ethernet cable (in case of PoE), watch the status of the device (table: visual display), release the Key/Button after time shown in the table. If you want to reanimate this devices now with GWLoad, do not powercycle the device again. If the factory reset was successful the device is now in the defined TFTP-Mode and ready for GWLoad. If you just wanted to factory reset the device you can do a powercycle for sure.

If the factory reset was not successful please contact rma@innovaphone.com

or look at [[Howto:Get Access to Gateways if the Assistant don't boot the device.]]

{| border=1
!Device (visual display)
!Reset Button/Key
!Button pressed
!Clear Config
Firmware
Boot code update
!Pressing Button to TFTP without deleting config in seconds ca.
!Pressing Button to factory reset in seconds ca.
!GWLoad- / TFTP-Mode
!Firmware starting
!Firmware ready
!Firmware Error
|----
|IP21
(all LED's)
|Button
|ready: <5s blink, >5s constant flash

line1 + line2 + door + aux constant flash / link + act off

with plugged in ethernet cable 100M + link: <3s off, >3s normal operating state
|...

ready fast blink, line1 + line2 + door + aux off link + 100M normal operating

|3
|25
|all LED’s are constant flashing

link is blinking
|ready + line1/2 + door + aux + 100M (if link)

permanent for ca. 5s

link blinking
|ready + 100M (if link)

link blinking
|
|----
|IP400
(all LED’s)
|Button
|PPP+Tel.1+Tel.2: <5s blink, [5;8] constant flash, >8 ready + link + act constant flash

without ethernet cable plugged in: <8s off, 8s one blink, >8s off
|
|3
|25
|ready + link + act flashing constant
|<8 ready + PPP + tel1 + tel2 constant flash,

[3;10] link + act. uncoordinated flashing

>10s ready + link (if link) constant act. blinking
|ready + 100M (if link)

link blinking
|
|----
|IP3000
(all LED’s)
|Button
|<6s PRI1+PRI2+S/T+ready blink, [6;10] PRI1 + PRI2 + S/T + ready constant flash,

act + speed + link off

>10s PRI1 + PRI2 + S/T constant flash, ready + act + speed + link off

with ethernet cable plugged in: act + speed + link normal working state
|fast blink (green)
|3
|25
|all LED’s flashing permanent

ready off

link blinking
|>2 link + speed constant flashing, act blinking

<5s PRI1 + PRI2 + S/T constant flash

>5s ready constant flash, (if link) link + speed constant flashing, act blinking
|ready constant flash, (if link) link + speed constant flashing, act blinking
|blinking (green)
|----
|IP800/IP6000/IPx010
(red/green/orange ready LED )
|Button
|<6 slow gn blink

[6;10] constant red

[10;13] fast gn blink

<13 constant orange
|fast blink (green)
|3
|15 (IP800)

15-20 (IP6000/IPx010)
|constant orange
|red
|green
|blinking (red)
|----
|IP1200
|Button
|<2s alarm red constant flash, ready off

[2;7] alarm off, ready slow blink green

[7;13] alarm off, ready fast blink green

>13s alarm off, ready 2 Hz blink green
|fast blink
|3
|10
|slow flash ca. 2 Hz
|<2s alarm red constant flash

ready green constant flash

power orange constant flash

[2;4] alarm off, ready off, power orange

>4s alarm off, ready constant green flash, power constant green flash
|ready constant green flash and power constant orange flash
|alarm (red)
|----
|IP1202
|Button
|<3s LED off

[3;10] LED blink fast blue 1 sec

>10s LED blink fast blue 1 sec,
than blink slow blue until factory reset completed,
than constant yellow/amber
|fast blink in blue
|3
|10
|constant yellow/amber
|LED red until firmware lstarted

LED blink fast red until ethernet link up

LED blink fast blue until Air Sync established

LED constant blue if Air Sync OK

|LED constant blue
|LED constant red
|----
|IP200/IP202
(red handset)
|alt key
|slow blink
|slow blink
|3
|5
|constant flash
|slow blink
|off
|constant flash
|----
|IP200A/IP210
(red handset)
|alt key
|slow blink
|fast blink
|3
|15
|slow flash
ca. 2 Hz
|on
|off
|blinking
|----
|IP110
(LED’s in F1 key)
|save key
|slow blink
|F1 off
|3
|10 - 15
|slow flash
ca. 2 Hz
|constant F1 flash
|off
|blinking
|----
|IP101
(MWI LED)
|backspace key
|press key when power cycle, hold ca 10 sec till led flashing. Power cycle again when slow blink
|
|
|
|
|
|
|
|----
|IP102
(MWI LED)
|backspace key
|press key when power cycle, hold ca 10 sec till led flashing. Power cycle again when slow blink
|
|
|
|
|
|
|
|----
|IP111
(MWI LED)
|home key
|press key when power cycle, hold ca 10 sec till led flashing. Power cycle again when slow blink
|
|
|
|
|
|
|
|----
|IP112
(MWI LED)
|home key
|press key when power cycle, hold ca 10 sec till led flashing. Power cycle again when slow blink
|
|
|
|
|
|
|
|----
|IP230
(menu key)
|menu key
|slow blink
|fast blink
|3
|10
|slow flash
ca. 2 Hz
|on
|off
|blinking
|----
|IP240
(menu key)
|menu key
|slow blink
|fast blink
|3
|10
|slow flash
ca. 2 Hz
|on
|off
|blinking
|----
|IP241
(menu key)
|alt key
|slow blink
|fast blink
|3
|10
|slow flash
ca. 2 Hz
|on
|off
|blinking
|----
|IP222
(MWI LED)
|ESC key
|slow blink
|fast blink
|3
|15
|slow flash
ca. 2 Hz
|on
|off
|blinking
|----
|IP232
(MWI LED)
|ESC key
|slow blink
|fast blink
|3
|15
|slow flash
ca. 2 Hz
|on
|off
|blinking

|}

== Related Articles ==
* [[Howto:How to use gwload]]
* [[Howto:How_to_Reset_IPXXX_(V10...)]]

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

Howto:How to configure an IP phone for direct IP address dialing

2019-05-26T10:57:01Z

Ole: /* Configuration */

IP Phones can be configured to work without RAS, just by dialing IP addresses. Here is how.

==Applies To==
This information applies to

* All V6 IP Phones (except DECT)

Build sr1 and later.

==More Information==

===Problem Details===
Version 6 phones can work both with and without RAS (i.e. a Gatekeeper) simultaneously. This allows to work straight forward in environments, where normally there is a gatekeeper available but still to place and receive calls when the gatekeeper is gone for whatever reason.

Of course, the phone can also be entirely without a gatekeeper.

===System Requirements===
This function is implemented in the telephone, so it will work with V5, V6 and 3rd party gatekeepers. Please note though that you will need V6 phone firmware in any case (see above).

===Configuration===
To work with and without RAS simultaneously, 2 independent registrations have to be set up as follows
* Registration 1 will be the IP-only registration (which of course is self-contradictory). This is done by configuring 0.0.0.0 as Registration 1/Registration/Primary Gatekeeper Address
* To make sure there is a valid CLI when placing calls without gatekeeper, you should also configure the phones local IP address and extension as Registration 1/Registration/Name, just like 192.168.0.3#22 assuming 192.168.0.3 is your IP address and 22 is your extension
** If autodial is configured under Phone/Direct-Dialing, be sure to set the destination, ex 192*168*0*4#11, under Destination Name. If you put it under destination number, no outcalling calls will work after restart.
* Registration 2 will be your normal RAS registration. Please configure as usual. This registration has to be the active registration (that is the one that is normally used for outgoing and incoming calls). You need to set Phone/Registrations[Id=2]/Active for this
* You will probably want to have access to the local phone book from this 2nd registration. Use Registration 2/Directories/Local/Enable to switch this on.

Given that there might be no RAS available when placing a call, users will find it convenient to have all potential call destinations in their local phonebook. This can best be done using an import from excel (more precisely, from an CSV file).

Here is the columns definition for the CSV file:
{|border=1 |align=left
|align=left| '''Column''' || '''Meaning''' || '''Description'''
|-
|align=left| A || First Name || Columns A, B and C will be concatenated (space separated) to form the entries internal name
|-
|align=left| B || Surname ||
|-
|align=left| C || Organisation ||
|-
|align=left| D || Destination E.164 || Destination phone number
|-
|align=left| E || Destination Name || Destination name
|-
|align=left| F || Remarks ||
|-
|align=left| G || Flags || Must be FLAG_IP for IP direct destinations, empty otherwise. Put the destination IP address into column E!
If is set and this entry is dialled, then if the active registration is registered (RAS available), the number from column D is dialled. If RAS is not available, the IP address from column E is called directly.
|-
|align=left| H || Unused ||
|-
|align=left| I || Unused ||
|-
|align=left nowrap=true| J || Ringing Tone Melody ||
|-
|align=left nowrap=true| K || Ringing Tone Rhythm ||
|-
|align=left nowrap=true| L || Ringing Tone Volume ||
|-
|align=left| M || Source E.164 ||
|-
|align=left| N || Source Name ||
|}

To enter an IP destination manually into the local phone book, you will need to enter the IP address as H.323 name and leave the E.164 empty.

==== SIP configuration ====
To allow for inbound direct sip configure for User1 a SIP protocol, User ID: number#ip, eg 22#192.168.10.17, proxy: 0.0.0.0. Second registration as mentioned above

===Dialing IP Addresses===
'''H323 calls'''

You can dial an IP address directly from the phones keyboard. Simply dial e.g. 192*168*10*17 to call the endpoint at 192.168.10.17. If you need to dial an extension (e.g. because the destination really is a gateway), you can add this extension like #22 (assuming you want to dial extension 20), which makes 192*168*10*17#22.

Obviously, only block dialing is possible this way.

'''SIP calls'''

You can dial an IP address directly from the phones keyboard. The syntax is different to H.323, it is sip:number@ip-address. If the endpoint is e.g. 22 and the IP address e.g. 192.168.10.17, you must dial sip:22@192.168.10.17



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

Reference10:Voice Player/Setup

2015-06-09T08:59:46Z

Ole: /* Recorder Address */

= Player Setup =

This decription concerns the Player Setup

[[Image:PlayerSetup01.png]]

The setup is shown always on the position where the player is located but is an independent window and can be moved.

== Main Window ==
=== Always in foreground ===
Hold the player window in foreground. Note that the foreground option for the iQM Recall window can be enabled independently (see relative Tab).

=== Start minimized ===

If checked this application starts-up minimized in the taskbar.

=== Help (online) ===
Starts up this help

=== Exit (no save) ===
Exit setup without storing eventual changed options

=== Save and Exit ===
Saves the actual setup and close the setup window. Some options like new ports require a restart while option like showing or not a button not.

=== Save + Stop! ===
(Build 1074 or higher)
Saves the actual setup and close the application.

=== Version ===
In the left lower edge the actual version of the payer (Build) is displayed.

== TAB General ==

=== Player Name ===

Define the Name of this Player (useing the CN user name is recommended), this name will appear on the main player window but will also identify the user in the central log file. If the Player communicate with the recorder the name is even required, also if the player should be integrated in a external application.
If the player interacts with the iQM the name must be the CN (the same name than associated to a agent client) otherwise no recall is possible.

=== Setup Password ===

If blank no password is required to access to this setup. If a password is defined it must be entered to access this setup. If a password is entered or changed the firmware check if in the indicated recording directory a centralized password is found. If yes this master password must be indicated correctly. This is done to avoid that a user delete the setup file, starts the player and access to the setup indicating the recording path and then being able to manipulate.

=== See just number(s) ===

The extension number indicated here is copied to the “Filter A” field of the Player. The “filter A” field is disabled automatically and therefore this user will see just “his” recordings. Like in the filter A and B fields also here wildcards can be used. “2?” for example will show all records from extension “20” to “29” while “203” will show just records of extension 203. If leaved blank this feature is off and the “Filter A” field enabled.

Build 1077:

It is possible indicate more extension numbers separated by a semicolon. In this case a drop down selection field will appear and the desired extension as filter can be selected.

This is usefully when for example a supervisor should see all his agents’ calls (but not any recorded call).

Example: "33,39,24" will enable this user to see the call of this extensions.

[[Image:MoreUSR.png]]

The order in the drop down is the one indicated in the input field of the setup.

=== Player Password ===
With this password the player can be protected, if a password is in and the application started a cover is over the player.
To unlock press the lock key and enter the password.

=== Decrypt Key ===
The recorder crypt the record data files (the XML) using an internal standard key. If a User Key is defined encryption is done using this key. Therefore even in a player has to be configured this key.

Leave this field blank if no User Key is defined. If mixed encryption files are present (files with standard system key and user key) the right key will be used automatically.

If audio files are encrypted this key is also used to decrypt, the same key is used for encryption of the record data file and the audio file.

=== Set recording directory root ===

If pressed a directory dialog is opened and the path to the root directory of the recorder can be selected. Only in this way a normal browsing if the recorded records is possible. The root directory is the same one than the on indicated in the recorder (storage path).

===Work with http Player-Server===

(Build 1074 or higher)

If checked the Player will get all his information from a player server. Set this socket (IP address and port number) to the same value as indicated in the player server.

Note: The root Recording directory must be set or here or in the player server.

Note: Some features are disabled or not available if this mode is selected. See relative Howto in the related articles.

== TAB Permissions ==

With these options you modify also the layout of the player, if not checked the relative buttons are not displayed.

=== Allow copy records ===

If checked records can be copied, if not the relative button is not shown in the player.

=== Allow move (cut out) records ===

If checked records can be moved to other directories, if not the relative button is not shown in the player. Note that the move or delete button is never shown on backup directory.

=== Allow delete records ===

If checked the user can delete records, if not the relative button is not shown in the player. Note that the move or delete button is never shown on backup directory.

=== Allow delete without recorder connection ===

If checked, records can be deleted even without an established connection to the recorder. As default deleting records is possible only if this player has a working IP connection to the Recorder. This is used to synchronize the reporting tool.

=== Write record manipulation Log ===

If checked each copy, move or delete action will be logged in a central log file on the recorder directory (therefore all manipulations are logged in one single log file). Please note that copy move and delete operations are possible just on the working folders where the player is pointing (and typically not in the backup path).

=== Use also as Audio player ===

If checked free browsing and playing of audio and video files is possible.

The following file types are supported:

Audio: .wav, .mp3, .wma

Video: .avi, .wmv, .mp4, .mpg

=== Allow edit record notes ===

If checked near the note text filed a button “Note” is displayed. The user can edit the note field and save the note pressing the note button. If non checked no “Note” button is displayed, but existing Notes are displayed.

=== Allow export of encoded files ===

If checked a record loaded in the player can be stopped and an export is possible. Export means a copy of clear data, so the XML file is readable while the audio file, if encoded, is stored as a clear copy (clear Wave or mp3 format, depends on the original file format).

=== Allow instant Play ===

If not checked the relative button and function will be hided. The instand Play option shows the latest records on top and diseables some filter options. This mode is used typically in emergency scenarios.

=== Allow transcription ===

If not checked the relative button and function will be hided. Transcription is uses if a written copy of a conversation has to be produced.

=== Show memory===

If not checked it is not possible to switch on the memory (snap) indicator.

Build 1072

===Show record details ===

If not checked the CDR details are not displayed in the relative window.

=== Show historic timestamp===

If not checked the user cannot activate the real time display of the historic timestamp.

=== Store last ___ tracks played===

The recorder shows in a special view the list of the last records played. Insert “0” for disable the feature, the maximum value is 99.
The list is updated automatically each time a record is played and the track is not jet in the list. The list of the played tracks can be sorted, filtered and marked as usual. Marked tracks can also be deleted from the list.

Note: The list described is just a list and represent not the real record. Therefore a delete just deletes the entry in this list, not the record itself.

Build 1071

===Allow mark personal record===

If checked a relative key (my) is show on top of the record list and during a play a key to save the record is displayed in the recorder section.

A “personal record” is a record reproduced on this specific player (PC) while a system playlist is available to all players in a network.

The list is like the one of the last tracks played.

If the feature “allow public mark record” is switched on a copy key will be automatically displayed if the show personal record key is pressed. Marked entry can be copy to the public folder pressing the copy key.

Build 1071

=== Allow public mark record===

The marked records are stored in a network wide, for all player available playlist.

See Store last and mark personal for details.

Build 1071

===Store activity in central log===

If checked all records played are stored in a central list. Not the track itself but the activity is reported, indicating date and time, the name of the player and the record. Each play will be reported, so even a eventual looping (repeating) of a record.

The log file is stored in the directory LOG of the recorder and a text file named “Playerlog.txt”. There is no utility but it can be imported in excel.

Example for entry’s:

19.09.2014 18:13:04,Klaus,2014_06_03_1651_24.i.0102_1_20ca5319e909d31190d60090331b3e3b.wav

22.09.2014 13:24:07,Klaus,2014_06_03_1559_24.o.0102_1_ac26f097e909d311b3e700903306225f.wav

== TAB Backup ==

=== Allow access to backup files ===

Enable browsing records in the backup directory, move and delete buttons are hided. The Year and month has to be entered manually, online browsing is not possible (setup search valued and press the search button).

Note that this feature is just on if also a relative backup directory is defined and online.

=== Set Backup directory ===

If pressed a directory dialog is opened and the path to the backup directory of the recorder can be selected. The backup directory is the same one than the on indicated in the recorder (backup storage path).

== TAB Link to Recorder ==

If this option is on the player shows the status of the recorder and can synchronize deleted files with the reporting database.

=== Recorder Address ===

IP Address from the recorder, could be 127.0.0.1 if running on the same PC, leave blank to switch feature off.

=== Recorder Port ===

Same port than the one indicated in the recorder setup (com with Player), leave blank if you don’t want that this player communicates with the recorder. Do not enter a value if no connection is desired, because continuous error attempts to reach the recorder will occur.

Do not confuse with the other port numbers in this setup, duplicate port numbers will cause a system crash; the port number must even be free from the PC point of view. 9001 to 9099 could be a good range.

== TAB Link to iQM ==

This option allows displaying in the player the list of the abandoned calls of the Waiting Queue. Used in emergency scenarios, where missed calls are a critical event.

=== Common Name ===

Common Name of the phone associated to the player. Required for recall directly from the recall list (the phone goes off hock and calls the abbandoned caller).

=== iQM TCP/IP Address ===

Enter the IP Address of the iQM server (see eventually setup iQM). Leave blank to switch off the feature. Do not enter data if no iQM server is online, the player will try continuously to reach the iQM server and slow down the system.

=== iQM Port ===

Enter the Port of the iQM server (see eventually setup iQM).

Do not confuse this setup with the other port numbers in this setup, duplicate port numbers will cause a system crash; the port number must even be free from the PC point of view. 9001 to 9099 could be a good range.

=== Dock on player ===

The (independent) recall window will be docked to the player window.

=== Recall list always in foreground ===

Hold the recall window in foreground. Note that the player window can be enabled independently.

== TAB Remote Control ==

As the name says this is the first party remote control interface. If the interfacing with an external application is done using the 3rt party interface this option is not required.

=== Port for RC ===

Port for remote control of the player, the IP address is the one of the PC where this program is executed and could not be modified here.

The reporting is anyway using too this port for reproducing calls, this port must for that application be the same than the one indicated in the setup of the reporting.

=== Reporting RC ===

Leave blank to switch off the feature, if set a restart of the player is required, near the record ID “RC on” is displayed.

=== Pop up on play if minimized ===

If checked the player will pop up if minimized in the taskbar and a remote “Play” command is received.

=== Minimized if Stopped ===

If checked and a remote control command stops the player the player is automatically minimized.

== Map ==
As explained on the TAB a User PC must have access to the directory where the records are. So basically that is an issue of the system administrator. If a network path is enable it will be displayed in the file list after pressing the “Set” button.
It is also possible map a network drive on the PC to that path and then access to that drive.
At least, and this is this option, also the player itself is able to map a network drive (and disconnect it when the program is terminated). This tab is to allow that scenario.

=== Connect automatically ===
If not checked the map is off, if checked and a drive is indicated the software try to connect the network drive on start-up.

=== Drive ===
The list shows the available network disk on this PC starting search after the letter “C”.
=== User and Password ===
The credentials to access to this network drive
=== Path ===
Path to the network drive (try eventually first with a normal explorer to connect a network drive and copy the path in there)

=== Connect ===
If you press that button and the network drive is not connected the software try to connect, the status is displayed nearby.
Note that you must first connect the drive and then set up in General the root directory.
=== Remove ===
Disconnect a connected network drive.

== Files ==

The setup files are stored in the directory “user\AppData\roaming\innovaphone\innovaphone Player”.
For different path options see

* [[Reference10:Voice_Recorder/Setup#Player]]

The Setup is stored in a file named “iPlayer_Setup.xml”.

The file is an xml file but his contend is encrypted and can therefore not be manipulated manually.

The local error and events are stored in a text file named “iPlay_Sys_Log.txt” in the directory where the software is running.

The last player position on the screen is stored in a file named “PlayerPos.txt”, if this file is missing or deleted the player will start up on the windows default startup position.

Note: If the application starts on a hide position you can track it back to the main window activating the application on the taskbar and press the windows button + shift + left arrow.

The manual setup of the Player is stored in a file named “iPlayer_User_Setup.xml”. This file contains the actual values and options, for example the actual selected player volume. If the Player starts up again the user will found his previous selected switched and options.

== Multiple Voice Recorder and Player ==

See
* [[Reference10:Voice_Recorder/Setup#Multiple_Voice_Recorder_and_Player]]

== Related Articles ==

[[Reference10:Concept_Voice_Recorder]]

[[Reference10:Player_Voice_Recording]]

[[Reference10:Voice_Recorder/Setup]]

[[Howto:Last_Call_Recording]]

[[Howto:Universal_Track_Recording_Tool]]

[[Reference10:Voice_Recorder/Setup]]

[[Howto:Player_over_http]]

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

File:Screenshot v11 feil testperiode utlopt.PNG

2015-01-21T14:56:46Z

Ole: Ldap phonebook service for Norway - error message

Ldap phonebook service for Norway - error message

File:Ldap Reporting setting.PNG

2015-01-21T14:43:20Z

Ole: Ldap phonebook service for Norway - Reporting setting

Ldap phonebook service for Norway - Reporting setting

File:Screenshot Phone directory.PNG

2015-01-21T14:38:43Z

Ole: Ldap phonebook service for Norway - External Ldap server

Ldap phonebook service for Norway - External Ldap server

File:Screenshot myPBX feil manglende betaling.PNG

2015-01-21T14:11:12Z

Ole: Ldap phonebook service for Norway - error message

Ldap phonebook service for Norway - error message

File:Screenshot v11 feil manglende betaling.PNG

2015-01-21T13:54:41Z

Ole: Ldap phonebook service for Norway - error message

Ldap phonebook service for Norway - error message

File:Screenshot myPBX feil testperiode utlopt.PNG

2015-01-21T13:53:44Z

Ole: Ldap phonebook service for Norway - error message

Ldap phonebook service for Norway - error message

File:Screenshot myPBX feil testperiode utløpt.PNG

2015-01-21T13:50:41Z

Ole: Ldap phonebook service for Norway - error message

Ldap phonebook service for Norway - error message

File:Screenshot myPBX feil user-pw.PNG

2015-01-21T13:50:14Z

Ole: Ldap phonebook service for Norway - error message

Ldap phonebook service for Norway - error message

File:Screenshot v11 feil ip-adresse.PNG

2015-01-21T13:48:43Z

Ole: Ldap phonebook service for Norway - error message

Ldap phonebook service for Norway - error message

File:Screenshot myPBX feil ip-adresse.PNG

2015-01-21T13:47:35Z

Ole: Ldap phonebook service for Norway - error message

Ldap phonebook service for Norway - error message

File:Screenshot myPBX telefonlogg.PNG

2015-01-21T13:46:37Z

Ole: Ldap phonebook service for Norway - myPBX call log

Ldap phonebook service for Norway - myPBX call log

File:Screenshot myPBX predial.PNG

2015-01-21T13:45:06Z

Ole: Ldap phonebook service for Norway - myPBX predial

Ldap phonebook service for Norway - myPBX predial

File:Screenshot myPBX oppslag.PNG

2015-01-21T13:44:22Z

Ole: Ldap phonebook service for Norway - myPBX

Ldap phonebook service for Norway - myPBX

File:Screenshot myPBX popup.PNG

2015-01-21T13:43:07Z

Ole: Ldap phonebook service for Norway - myPBX popup

Ldap phonebook service for Norway - myPBX popup

File:Screenshot v10 telefonlogg.PNG

2015-01-21T13:41:49Z

Ole: Ldap phonebook service for Norway - call log

Ldap phonebook service for Norway - call log

File:Screenshot v11 telefonlogg.PNG

2015-01-21T13:40:43Z

Ole: Ldap phonebook service for Norway - call log

Ldap phonebook service for Norway - call log

File:Screenshot v10 predial.PNG

2015-01-21T13:39:51Z

Ole: Ldap phonebook service for Norway - outgoing call

Ldap phonebook service for Norway - outgoing call

File:Screenshot v11 predial.PNG

2015-01-21T13:38:44Z

Ole: Ldap phonebook service for Norway - outgoing call

Ldap phonebook service for Norway - outgoing call

File:Screenshot v6 oppslag.PNG

2015-01-21T13:36:37Z

Ole: Ldap phonebook service for Norway - incomming call

Ldap phonebook service for Norway - incomming call

File:Screenshot v10 oppslag.PNG

2015-01-21T13:35:38Z

Ole: Ldap phonebook service for Norway - incomming call

Ldap phonebook service for Norway - incomming call

File:Screenshot v11 oppslag.PNG

2015-01-21T13:33:00Z

Ole: Ldap Norwegian phonebook service - incomming call

Ldap Norwegian phonebook service - incomming call

File:Screenshot admin ny kunde.PNG

2015-01-21T07:38:19Z

Ole: Eksempel på innlegging av ny kunde i admin-portalen for Telefonbok Norge

Eksempel på innlegging av ny kunde i admin-portalen for Telefonbok Norge

Howto:Simple Wake-UP Service

2014-11-20T09:39:44Z

Ole: /* Download */

{{3rd Party Input}}
This article describes a simple Wake-Up service.
Any improvements are encouraged!

==Applies To==
innovaphone PBX, V7 or higher for version 1.4 of perl script

innovaphone PBX, V9 hotfix 22 or higher for version 2.0 of perl script



==More Information==
The wake-up call is a typical Hotel or TelCo service. Innovaphone does not support wake-up calls natively but you can build this service with a simple XML and PERL script.

====XML script====
The wakeup.xml feature is realized using Innovaphone XML Voicemail script, no license is required for this feature.
If you call the script a main menu is played. In this menu you can select 1 for set the wake-up time, 2 for disable the wake-up or 3 to check the configured alarm time.
The XML gets the alarm time via DTMF. It must be specified in 24 hours format as explained in examples below:

1030 means 10 am and 30 minutes

2230 means 10 pm and 30 minutes

0700 means 7 am o'clock

0000 means midnight

Once the alarm time is setted, the XML writes a txt file in the "alarm" folder. Files have this particular format: file name is equal to calling party number and file content is the alarm time in 24 hours format with : as separator between hours and minutes.
The calling party number will be used as called number and re-called when will be the time to wake-up.
In this way a user can set only his wake-up and can set again the time without disable it. Every time that a user select the option to enable the wake-up, the XML rewrites the file in the "alarm" folder with the new time.
Obviously, if the calling party number is missing or restricted the XML will prompt an error message.
To disable the alarm the XML deletes the file. Examples:

ext. 101 calls XML and sets 0800 ---> XML writes the file 101.txt with the content 08:00

ext. 101 recalls XML and sets 0830 ---> XML rewrite the file 101.txt with the content 08:30

ext. 101 recalls XML and disables the wake-up ---> XML deletes the file 101.txt

====PERL script====
PERL is an interpreted language and so can be executed on Linux and Windows operating systems. Linux can interpret perl natively while for Windows you can download many free interpreters like Activeperl or Strawberry perl.
To run the script send_call.pl you must use a third party server or the Innovaphone Linux Application Platform.
The reason of a PERL script is the following: the Innovaphone XML script can't start a call and so is necessary an external agent.
The script runs in background as a service and performs the following tasks:

- every minute checks the folder called "alarm"

- reads files

- uses the file name as called number

- checks the file content to verify if is wake up time

The version 1.4 of the script uses SIP and handles 4 call responses: 404 user not found, 486 busy, 487 not answer and 200 answer ok.
In every cases sends an email and deletes files. Only for the answer case plays a nice music.

The version 2.0 uses the Innovaphone CallBack function to generate a call (for more info see the Related Articles at the bottom of the page). This release doesn't handle the call state like busy or not answer.

==Configuration==
Create a VM object in your PBX and put in the “Script URL” the path of your XML object. Example of configuration of a directory called "wakeup":

http://xxx.yyy.zzz.vvv/inno/wakeup/wakeup.xml

Assign a number to this object, now you can call it from any phone and the main menu will be prompted.

[[Image:voicemail_obj.PNG]]

Create a GW without registration with the IP Address of the server where is running the PERL script.
Create a route from the GW created just now to the GW registered as PBX TRUNK line.
In this way you can permit calls from PERL script to PBX.

[[Image:gw_route.PNG]]

Open the PERL script with a text editor and configure the global parameters at the beginning of the file as showed in example below:

[[Image:perl_global.PNG]]

The version 1.4 handles 4 sip responses: 404 user not found, 486 busy, 487 not answer and 200 answer ok. If you want add a new cause you can edit the script and create a new condition.

The music played during connection uses the G.711A codec. If you want change it you must modify the rtp_param [ 8, 160, 160/8000, 'PCMA/8000' ] in the "invite" routine.

[[Image:perl_sip_ua.png]]

If you want, there is an optional feature to register the Perl SIP agent to your PBX: #$ua->register ( expires => "300",). It's disabled per default.

Only for version 2.0 you must have a Waiting Queue object in your PBX used to generate the call and play the Wake Up music.

If you want execute the script in a service mode, you must edit rc.local in your Linux OS file and write the istruction: "perl /your script path/send_call.pl 2>&1 & "

==Localization==
This script is delivered with Italian prompts, but you can produce your own prompts and wordings. Audio files are in the "audio" folder. Files are following:

Filename: Prompt

welcomemenu: “press 1 to set the wake-up, press 2 to disable wake-up, press 3 to check wake-up status”

Invalidcgpn: “the calling party number is missing or restricted, the service can not be activated”

wrongselection: “the selected option is invalid”

timemenu: "set the time in 24 hours format"

wrongtime: "the time selected is invalid"

finalok: "wake-up service enable"

cancelalarm: "wake-up service disable"

timeis: "setted time is"

min: "minutes"

0..23: hours followed by "and"

n00..n59: minutes

Wakeupmsg: nice music wake-up alert (used in version 1.4 only; in version 2.0 the wake up music is generated by the PBX Waiting Queue object)

==Known Problems==
In version 1.4, if you activate the Authentication for SIP messages and there are more then two simultaneous calls, the script sends some INVITEs without authentication or with wrong checksum and so not all phones ring.

==Download==
[[media:wakeup.zip]]

XML revisioned by Marc Steiner, inikon AG: [[media:wakeup-xml.zip]]

New version of send_call.pl (v1.4 April 2012): [[media:send_call_perl.zip]]

Alternative version of send_call.pl (v2.0 september 2013): [[media:send_call_2_0_perl.zip]]

Wakeup XML script with norwegian promts, by Vcom - Norway. (11. November 2014): [[Media:Wakeup_NO.zip]]

* Compared to the original wakeup script, this script allow dtmf choices to interrupting the voice promts. The script is also prepared for multi language. New prompts in other languages can be added with the file prefix XX_. Line 9 in the XML script choose language.
* All promts for hours and minutes can be taken from the innovaphone voicemail promts.
* Vcom has also created a script for a Linux cron job that can be placed direct on IPx10 application platform. The advantage with this script compared with the Pearl script, is autostart of the script after a reboot of IPx10. Contact support@vcom.no for more info.

== Related Articles ==
[[Howto:Initiate a Mobility CallBack via simple HTTP GET or POST request]]

Howto:Simple Wake-UP Service

2014-11-11T16:25:40Z

Ole: /* Download */ norwegian promts

{{3rd Party Input}}
This article describes a simple Wake-Up service.
Any improvements are encouraged!

==Applies To==
innovaphone PBX, V7 or higher for version 1.4 of perl script

innovaphone PBX, V9 hotfix 22 or higher for version 2.0 of perl script



==More Information==
The wake-up call is a typical Hotel or TelCo service. Innovaphone does not support wake-up calls natively but you can build this service with a simple XML and PERL script.

====XML script====
The wakeup.xml feature is realized using Innovaphone XML Voicemail script, no license is required for this feature.
If you call the script a main menu is played. In this menu you can select 1 for set the wake-up time, 2 for disable the wake-up or 3 to check the configured alarm time.
The XML gets the alarm time via DTMF. It must be specified in 24 hours format as explained in examples below:

1030 means 10 am and 30 minutes

2230 means 10 pm and 30 minutes

0700 means 7 am o'clock

0000 means midnight

Once the alarm time is setted, the XML writes a txt file in the "alarm" folder. Files have this particular format: file name is equal to calling party number and file content is the alarm time in 24 hours format with : as separator between hours and minutes.
The calling party number will be used as called number and re-called when will be the time to wake-up.
In this way a user can set only his wake-up and can set again the time without disable it. Every time that a user select the option to enable the wake-up, the XML rewrites the file in the "alarm" folder with the new time.
Obviously, if the calling party number is missing or restricted the XML will prompt an error message.
To disable the alarm the XML deletes the file. Examples:

ext. 101 calls XML and sets 0800 ---> XML writes the file 101.txt with the content 08:00

ext. 101 recalls XML and sets 0830 ---> XML rewrite the file 101.txt with the content 08:30

ext. 101 recalls XML and disables the wake-up ---> XML deletes the file 101.txt

====PERL script====
PERL is an interpreted language and so can be executed on Linux and Windows operating systems. Linux can interpret perl natively while for Windows you can download many free interpreters like Activeperl or Strawberry perl.
To run the script send_call.pl you must use a third party server or the Innovaphone Linux Application Platform.
The reason of a PERL script is the following: the Innovaphone XML script can't start a call and so is necessary an external agent.
The script runs in background as a service and performs the following tasks:

- every minute checks the folder called "alarm"

- reads files

- uses the file name as called number

- checks the file content to verify if is wake up time

The version 1.4 of the script uses SIP and handles 4 call responses: 404 user not found, 486 busy, 487 not answer and 200 answer ok.
In every cases sends an email and deletes files. Only for the answer case plays a nice music.

The version 2.0 uses the Innovaphone CallBack function to generate a call (for more info see the Related Articles at the bottom of the page). This release doesn't handle the call state like busy or not answer.

==Configuration==
Create a VM object in your PBX and put in the “Script URL” the path of your XML object. Example of configuration of a directory called "wakeup":

http://xxx.yyy.zzz.vvv/inno/wakeup/wakeup.xml

Assign a number to this object, now you can call it from any phone and the main menu will be prompted.

[[Image:voicemail_obj.PNG]]

Create a GW without registration with the IP Address of the server where is running the PERL script.
Create a route from the GW created just now to the GW registered as PBX TRUNK line.
In this way you can permit calls from PERL script to PBX.

[[Image:gw_route.PNG]]

Open the PERL script with a text editor and configure the global parameters at the beginning of the file as showed in example below:

[[Image:perl_global.PNG]]

The version 1.4 handles 4 sip responses: 404 user not found, 486 busy, 487 not answer and 200 answer ok. If you want add a new cause you can edit the script and create a new condition.

The music played during connection uses the G.711A codec. If you want change it you must modify the rtp_param [ 8, 160, 160/8000, 'PCMA/8000' ] in the "invite" routine.

[[Image:perl_sip_ua.png]]

If you want, there is an optional feature to register the Perl SIP agent to your PBX: #$ua->register ( expires => "300",). It's disabled per default.

Only for version 2.0 you must have a Waiting Queue object in your PBX used to generate the call and play the Wake Up music.

If you want execute the script in a service mode, you must edit rc.local in your Linux OS file and write the istruction: "perl /your script path/send_call.pl 2>&1 & "

==Localization==
This script is delivered with Italian prompts, but you can produce your own prompts and wordings. Audio files are in the "audio" folder. Files are following:

Filename: Prompt

welcomemenu: “press 1 to set the wake-up, press 2 to disable wake-up, press 3 to check wake-up status”

Invalidcgpn: “the calling party number is missing or restricted, the service can not be activated”

wrongselection: “the selected option is invalid”

timemenu: "set the time in 24 hours format"

wrongtime: "the time selected is invalid"

finalok: "wake-up service enable"

cancelalarm: "wake-up service disable"

timeis: "setted time is"

min: "minutes"

0..23: hours followed by "and"

n00..n59: minutes

Wakeupmsg: nice music wake-up alert (used in version 1.4 only; in version 2.0 the wake up music is generated by the PBX Waiting Queue object)

==Known Problems==
In version 1.4, if you activate the Authentication for SIP messages and there are more then two simultaneous calls, the script sends some INVITEs without authentication or with wrong checksum and so not all phones ring.

==Download==
[[media:wakeup.zip]]

XML revisioned by Marc Steiner, inikon AG: [[media:wakeup-xml.zip]]

New version of send_call.pl (v1.4 April 2012): [[media:send_call_perl.zip]]

Alternative version of send_call.pl (v2.0 september 2013): [[media:send_call_2_0_perl.zip]]

Wakeup XML script with norwegian promts, by Vcom - Norway. (11. November 2014): [[Media:Wakeup_NO.zip]]

Compared to the original wakeup script, this script allow dtmf choices to interrupting the voice promts. The script is also prepared for multi language. New prompts in other languages can be added with the file prefix XX_
All promts for hours and minutes can be taken from the innovaphone voicemail promts.
Line 9 in the XML script choose language.

== Related Articles ==
[[Howto:Initiate a Mobility CallBack via simple HTTP GET or POST request]]

File:Wakeup NO.zip

2014-11-11T16:18:31Z

Ole: Script for multi language. Contact Vcom for the Norwegian promts.

Script for multi language. Contact Vcom for the Norwegian promts.

Howto:Hosting with V10

2014-01-28T14:29:28Z

Ole: /* Configuration of customer related objects in the customer’s PBX and Frontend */

This document describes general recommendations for setting up a „hosted PBX“-environment. It is based on a reference implementation done early 2013. Everything said in this article is merely a recommendation and you may deviate from it for real-life projects. However, it may still serve as a guideline of “what to think of”.

There are no specific configurations given throughout the article. As such, it targets an iCE with some decent knowledge about innovaphone products as an audience.

This article is still “work in progress”.



=== Overview ===
Each customer receives a dedicated PBX (best run as IPVA). So no “dynamic PBX”s are used. Each customer has exactly one such PBX. So no Slave- (as they do not seem to make sense) and no Standby-PBX (as this is better implemented using VMware tools such as High Availability or Fault Tolerance). This article does explicitly not deal with mixed environments where some PBXs are hosted and some on-premise.

Further services (apart from the basic PBX) such as e.g. fax are provided by multi-tenant capable applications. How many customers and/or users (i.e. extensions) can be served by a single such application is for further study. However, from an administration point-of-view, it seems to be easier calculating the same application-server to number-of-customers ratio for all the applications, as it allows organizing the whole setups in clusters where a specific set of customers is associated to a specific set of application servers.

In a real-life setup, there may or probably will be a central management server which may run software to simplify the management of the whole setup as well as provide an end customer portal. This server, called ‘’Management Server‘‘ in the overview graph is thought to be specific to the PBX hosting provider and is thus – although it has an important impact – not discussed in this document.

[[Image:Cloudkom-grobuebersicht1.png]]

Most of the hosted services, as well the customer-PBXs and the shared services, will be located in a private network run by the hosting provider. This is to make sure they cannot be easily attacked and also to save on publicly available IP addresses (which may be a scarce resource). As a result, from a TCP/IP point-of-view, these services are not reachable from the customers own private network. Also, to save on resources and reduce complexity, no VPN is set up between the customer and the hosting provider. To implement the required customer access to these services, there are 2 extra services which need to have an additional external IP address (“dual homed”). These are called “Frontend” and “Media-PBX”.

The Frontend provides:

* Proxy registration of customers terminal devices (e.g. phones) located on premise to the customer PBX
: Terminals in fact register with the Frontend which in turn entertains a proxy-registration to the customer PBX for each endpoint
* inbound NAT with port maps for selected protocols (such as e.g. HTTPS/443 und LDAPS/636,714)

The Media-PBX

* provides a reachable media endpoint for media data provided or consumed by services within the hosting providers private newtork
: This includes e.g. ''music on hold'', locally generated calling tones, Voicemail, multi-party conferences and fax
This architecture ensures that the hosting providers network topology is invisible to 3rd parties (including possible attackers). Furthermore, the hosting provider only needs 2*n+1 public IP Addresses (where ''n'' is the number of ''shared service'' groups).
The “dual homed” gateways must be configured to have ETH0 (default interface) connected to the ''public network'' and ETH1 connected to the ''hoster network''.
[[Image:Cloudkom-netzuebersicht1.png]]



==== SIP Provider ====
Each customer has its own SIP trunk, configured on the according customer IPVA. The SIP trunk must be configured without using MediaRelay. As a result, if a customer makes a call to the PSTN(SIP provider), the RTP-stream goes end-to-end - between the SIP-provider and the phone at the customer site. Since the customer phone is behind a NAT router, the SIP provider must support NAT traversal.

In general a [[:Category:3rdParty SIP Provider|certified SIP-provider]] can be used, if the provider passed the interop-test for [[Howto:SIP_Interop_Test_Description#NAT_Detection.28Important.29 | NAT Traversal]], [[Howto:SIP_Interop_Test_Description#Fax_using_T.38.28Important.29 | T.38]], [[Howto:SIP_Interop_Test_Description#Reverse_Media_Negotiation.28Important.29 | Reverse Media Negotiation]] and doesn't require MediaRelay to be enabled.

==== Passwords ====
Throughout the system, a number of passwords are used in various places. It is critical to use as less passwords as possible to make day-to-day administration easy and as much passwords as necessary to keep things secure. So here is an overview:

* Admin passwords
: Admin user authentication is based on Keberos. Each admin thus can and should have individual accounts and passwords (referred to as ''individual admin password'')
: all devices shall have a "local admin" passsword which should be kept secret and not be known by normal administrators and should normally never be used. This is referred to as ''system-wide admin password''
* PBX passwords
: PBX passwords needs to be the same in all oft the hosting providers PBXs (and do not need to be typed-in anywhere except during a PBXs initial configuration) . The are referred to as ''PBX password''
* Object password. There are 2 kinds:
** Passwords, which need to be known to the customer. Registration passwords for terminal devices would be an example. Those are referred to as ''customer registration password''). Another example are initial passwords for myPBX (that is, user passwords). They are referred to as ''customer login password''. For each customer (not for each line), a distinct ''customer registration password'' is defined, which normally never changes. Furthermore, another ''customer login password'' is generated, which is used initially for all user objects but will be changed by the end users.
** Password which are not disclosed to the customer. These are used for internal registrations, e.g. a local interface or gateway registering at the customer PBX. For this, the '' pbx password'' will always be used
* Kerberos DB password
: The ''PBX password'' shall be used for encryption of the Kerberos database (as it does make no sense to use a different password here)

Unfortunately, the Linux AP has no support for Kerberos so separate admin password are required. We distinguish passwords used during daily administration and those which are not.

* Linux Admin password
:this is the password used in day-to-day administration, referred to as ''Linux Admin password''. It is used as ''web server credentials'', ''webdav access credentials'', ''application access credentials'', 'innovaphone Reporting access credentials'', ''innovaphone Fax access credentials'' etc.
* Linux System password
: the password that is used as ''root credentials''. For this, the ''PBX password'' shall be used
: The database passwords (e.g. ''postgresql admin password'') can be left as by default, as the DB server is accessible from 127.0.0.1 only anyway

==== Customer-ID ====
Each customer should have a unqiue ''customer id''. It should be “safe” (that is, no umlaut, no spaces, no obscure special characters). Something like e.g. <code>Kuenkel0001</code> will do.
==== NTP ====
All devices require correct time setting. They all must have be a working NTP time source configured (and probably also a working alternate).

The ''dual-homed'' devices (see above) shall use 2 reliable time sources (either run by the hosting provider or from the internet). All other devices shall use "their" own Frontend as NTP Server (a backup time source is not strictly required here as these devices are anyway unusable for customers when the Frontend is down).

=== Certificates ===
The entire HTTP and LDAP traffic from and to the customers network is encrypted. This affects for example a customers access to the PBX (e.g. if the customer is granted (limited) access to the PBX config or for myPBX), as well as access to the reporting service.

To facilitate access to these devices without any warnings issued by the clients (e.g. browser security alerts) all devices require suitable certificates (that is, the host name and IP address must be noted in the certificate and they must be derived from a single signing authority so that end-users only need to import a single root certificate in order to accept all of these device certificates.

The devices built-in certifcates cannot be used as they only refer to the devices NetBIOS name (e.g. IPVA-a8-5a-38) which will not be used to access the devices. Also, in the case of IPVA, the default certificate is self-signed as opposed to being derived from the aforementioned uniform root certificate.

To derive device-certificates which all inherit from the same root certificate, a so-called ''RootCA'' is needed.

There are multiple ways to implement this. Although there are better schemes available, one way to do it that requires no 3rd party gear is to generate a RootCA (in ''General/Certificates/RootCA'') on a dedicated IPVA. This RootCA then can be used to generate all of the other certificates. They are stored in the IPVA’s virtual CF card (<code>/DRIVE/CF0/CA/certs/</code>) and can be exported to the other devices from there.

==== RootCA ====
For the RootCA, we use the IPVA that also implements the central Kerberos server. Unfortunately, with the current firmware each generated device certificate will also replace the IPVA’s own device certificate. This is of course somewhat unfortunate, however, it is not really an issue as no end-customer will ever access the Kerberos IPVA anyway. The Kerberos server itself does not rely on the device certificate.

You first generate a RootCA on the RootCA-IPVA ('General/Kerberos''). The following data must be used:

C=''your-country (e.g. Germany) '', O=''hoster'', CN=''hoster'' Device Certification Authority, Key-length 4096, lifetime 20 years

This new RootCA (which is now the IPVA’s device certificate) needs to be trusted on the IPVA (''General/Admin'').

==== Device Certificates ====
To create individual device certificates, use the RootCA created and use the following data:

Key 4096, Common Name=''devices NetBIOS Name, Organization=''hoster'', Country=''your-country (e.g. Germany) '', DNS Name 1=''devices external IP address'', DNS Name 2=''devices internal IP address'', IP Address 1=''devices external IP address '', IP Address 2=''devices internal IP address ''

For devices with an internal IP address only, it is important to specify the IP address of the NAT router used to access the device as external IP address (e.g. for a customer PBX, this will be the Frontend used). You specify the IP address only, not the port map.

If you intend to assign real DNS names to your devices, you may of course specify these as ''DNS Name 3'' too.

In order to be able to export the new certificate to the target device, you need to make sure you tick the ''Backup on CF'' check-mark, so it is saved on the CF as ''serialno''<code>.pem</code>. To transfer the new certificate to the target device, take note of the serial number and download the respective certificate file from <code>/DRIVE/CF0/CA/certs/</code>''serialno''<code>.pem</code>. This file can then be uploaded to the target device (''General / Certificates / Device certificate / Upload'').

==== Browser Installation of the Root Certificate ====
To get rid of the browser security alerts when accessing devices with e.g. HTTPS, the public key of the root certificate must be trusted by the browser. For this, it needs to be exported in to a file (you can best do this from the RootCA’s trust list in ''General/Certificates/Download/PEM'' into <code>certificate.crt</code>).

It must then be imported to the browser. This needs to be done once by both administrators and customers.

'''Firefox'''
* ''Extras / Einstellungen / Erweitert / Zertifikate anzeigen / Zertifizierungsstellen / Importieren''
* import the .crt file
* tick ''Dieser CA vertrauen, um Websites zu identifizieren''

'''Internet Explorer'''
* ''Extras / Internetoptionen / Inhalte / Zertifikate / Beabsichtigter Zweck Clientauthentifizierung / Vertrauenswürdige Stammzertifizierungsstellen / Importieren''
* import the .crt file

=== Kerberos ===
Kerberos is used to implement authentication for all devices. This includes both devices in the PBX hosting provider’s infrastructure and the CPE. For this to work, all devices must subscribe to the Kerberos realm. The PBX hosting provider’s DNS domain (e.g. ‘’hoster’’<code>.tld</code>) should be used as Kerberos domain name. This way, Kerberos can be found using DNS SRV records.

The IPVA used as RootCA can be used as master kerberos service too. A stand-alone Kerberos server (that is, the one that is implemented in the ''Gateway'' level) is being used. The (probably limited) number of admin accounts is maintained manually.

In fact, if the PBX hosting provider uses an active directory service to manage employee accounts, an AD-replicated PBX run on the central Kerberos IPVA is also a viable option.

Either way, a standby Kerberos server should be setup as a separate IPVA and can be replicated from the master kerberos as usual.

Unless an active directory is used, no trust relationships are required. If so, the ''system-wide admin password'' should be used as shared secret.

The devices which rely on kerberos for authentication (that is, all devices!) locate the Kerberos servers using DNS SRV records. Devices within the hosting provider’s private network use the internal IP address for this; external (e.g. CPE) devices use their respective Frontend. For this to work, each Frontend needs some UDP NAT maps as follows:

<pre>
Protocol Port Address Int. Port
UDP 7465 kerbhost-dup 464 delete
UDP 7464 kerbhost 464 delete
UDP 7089 kerbhost-dup 88 delete
UDP 7088 kerbhost 88 delete
</pre>

Instead of relying on the PBX hosting provider’s DNS server, the SRV records can be set in the devices during staging. This way, each device can be configured to use its associated Frontend only:

<pre>
config change DNS0 /a-name kerberos1i.#(h-domain)
/a-addr #(h-kerberos1ip) /a-name kerberos2i.#(h-domain)
/a-addr #(h-kerberos2ip) /a-name sbc#(h-sbcindex).#(h-domain)
/a-addr #(h-sbcextip)
/srv-name _kerberos._udp.#(h-domain) /srv-target kerberos1i.#(h-domain) /srv-port 88 /srv-prio 0 /srv-weight 0
/srv-name _kerberos._udp.#(h-domain) /srv-target kerberos2i.#(h-domain) /srv-port 88 /srv-prio 5 /srv-weight 0
/srv-name _kerberos._udp.#(h-domain) /srv-target sbc#(h-sbcindex).#(h-domain) /srv-port 7088 /srv-prio 10 /srv-weight 0
/srv-name _kerberos._udp.#(h-domain) /srv-target sbc#(h-sbcindex).#(h-domain) /srv-port 7089 /srv-prio 12 /srv-weight 0
/srv-name _kpasswd._udp.#(h-domain) /srv-target kerberos1i.#(h-domain) /srv-port 464 /srv-prio 0 /srv-weight 0
/srv-name _kpasswd._udp.#(h-domain) /srv-target sbc#(h-sbcindex).#(h-domain) /srv-port 7464 /srv-prio 10 /srv-weight 0
</pre>

With this setup, all devices will prefer the internal IP addresses. External (e.g. CPE) devices will of course not be able to reach these internal addresses, but they will succeed with one of the Frontends. Thus CPE devices will use any of the available Frontends, not necessarily their own. This will work as all Frontends ultimately NAT to the same Kerberos server.

Note: The ''_kpasswd._udp'' SRV entry should point only to the primary Kerberos Server (i.e. either external NAT-map or internal IP-address), since the ''_kpasswd._udp'' is used to join devices to the Kerberos-Realm. It is only possible to join a realm on the master-Kerberos server, not on the standby. As a result, if the Master-Kerberos server is down, it is not possible to join/unjoin device to the Kerberos-Realm.

==== Kerberos User ====
In addition to the accounts for the administrators, there must be a service account <code>paccess</code> used for programmatic access to the devices. This will for example be used by the Metadir server to access the Frontend (and can also be used by a hosting provider specific administration software). In addition to that, this account is to be configured under ''Services/HTTP/Client'' for URLs <code>https://</code> and <code>http://</code> on the Frontend, Media-PBX and customer PBXs. This allows all these device to access all other devices using HTTP/S.

The credential for this account need to be kept securely, as they allow admin access to all devices in the infrastructure!

To facilitate automatic join into the kerberos domain during staging, there needs to be an additional special account with ''Join Realm'' rights only: : <code>joiner, joiner</code>. This account is not particularly relevant from a security point of view, as aside from adding or removing devices from a realm nothing relevant can be done on behalf of it.

=== Licenses ===
It is in the PBX hosting provider’s best interest to implement a centralized license management. A central licensing server instance is needed thus. This can be run on the master and standby Kerberos server. All licenses purchased by the PBX hosting provider are installed here. The license server runs a PBX. The only task for this PBX is to host the licenses and distribute them to the Frontend and Media PBXs, which are registered as ''License only'' slaves and will further distribute the licenses to the customer PBXs (which are in turn registered as ''License only'' slaves to their respective Media-PBX).

If you choose to use a PBX based Kerberos server (see above), this same PBXs can be used.

The license server PBXs will have the PBX hosting provider’s domain name as ''System Name'' (e.g. <code>hoster.tld</code>) and <code>.</code> as ''PBX Name''.

=== Frontend ===
The Frontend

* accepts external registrations from customer CPE
* provides a central (virtual) CF-card storage for non-sensitive data (e.g. firmware files)
* supports mutliple customer PBXs. The exact number is yet ffs., however, we estimate no more than 135 currently. Frontends will simply be numbered (<code>sbc1</code>, <code>sbc2</code> etc.)
* The Frontend being a “dual homed” gateway, must have ETH0 (default interface) connected to the ''public network'' and ETH1 connected to the ''hoster network'', this was the tested setup during our tests so it's the recommended configuration.

==== NAT ====
* The Frontend will provide inbound NAT mappings for HTTPS and LDAPS. This allows for controlled access to the IPVAs within the PBX hosting provider’s private network from external. Each customer PBX uses its associated Frontend for NAT, that is, each Frontend provides NAT for all customers that have it associated as Frontend. The number of customers per Frontend is limited by the number of NAT maps that can be created, which in turn depends on the length of the resulting config file line. Currently, there is a limit of approximately 290 maps per Frontend. 2 distinctive maps are needed per customer
* Additionally, some maps shared by all customers (e.g. for services like Metadir, FaxServer, Reporting) are required. About 20 maps should be reserved for this
* So we end up with the aforementioned number of 135 customers per Frontend
* It is recommended to use a kind of syntax that allows the admin to deduce from the external port number the service type and the associated private IP. For example use 4-digit external ports, the first digit represents the service type(e.g.8 for HTTPS to the PBX, 9 for LDAPS to the PBX), the following 3 digits the associated IP-address(e.g. 007 for internal IP 10.0.0.7). In our example the external port 9007 would be mapped to the internal IP 10.0.0.7 port 636.
* since the Frontend is also used as NAT-router for UDP-messages(i.e. SIP signalling from the customer PBX to the SIP provider), an ''UDP-NAT port-range''(IP4/General/Settings) must be configured. The size of the port-range should be at least as large as the number of customer PBXs served by the Frontend, each SIP Trunk requires one (external, public) port in the defined range. By default the UDP-NAT port-range is ''0'', so no UDP NAT is possible. You must use a port range that does not conflict with other used ports on the Frontend (e.g. UDP-RTP Port-Range by default 16384 / 32767).

==== PBX ====
* ''System Name'' is the PBX hosting provider’s domain name (e.g. <code>hoster.tld</code>)
* ''PBX Name'' is <code>sbc</code>''n''
* ''Prefix for Intl/Ntl/Subscriber'' depending on Customers national numbering plan (e.g. for Germany and Trunk Prefix 0: <code>000, 00, 0</code>)
* registers as ''Slave PBX'' with the central license server PBX (''License Only'')
* receives required licenses from the central license server thus

===== Customer related Configuration =====
* One ''Session Border'' object for each (potential) terminal registration to a customer PBX
* ''Long Name'' as well as ''Registration to internal PBX/Name'' set tot he ''CPE-ID'' (see below)
* ''Password'' set to the ''customer registration password''
* ''Registration from external/Name'' set to the CPE’s hardware-ID (NetBIOS name) ''PBX Password'' ticked

See also [[#Configuration of customer related objects in the customer’s PBX and Frontend]]

=====Alternate RAS port=====
End-customer phones register to the PBX using H.323. Some CPE Routers (such as Linksys) are known to mess around with H.323 packets (namely RAS) may inhibit registration. To avoid this problem, the phones and Frontend should be configured to use an alternate port for RAS signalling. At the phone the RAS - port must be changed using the command <code>config add H323 /ras-port xxxx</code> , the Frontend must be configured to listen for RAS packets also on an alternate port using the command <code> config add H323 /ras-port-alt xxxx</code>.
The alternate RAS port configuration should be distributed to the phones in the staging section of the initial update-server configuration.

In few cases, the NAT router will still detect RAS-messages sent via an alternate RAS port. The NAT router will therefore do its faulty H323-NAT-entries in the RAS messages. As a result, phones behind the NAT-router will not be able to register at the Frontend.
Assuming that you configured the usage of an alternate RAS port and double-checked that the entered password (at the phone and Frontend) is correct/matching, you can enable the logging of H323-Registrations(Maintenance/Diagnostics/Logging) and look for a ''REGISTER-REJ'' message having the additional information ''Reason=Authentication failed''

REGISTER-REJ(200.205.64.202:9198),H323=IP200A-10-10-b4,Reason=Authentication failed

Since the password is correct, the Reason=Authentication failed indicates that the NAT router is still doing H323-NAT. To solve this problem, H323-NAT must be turned off on the NAT-router located at the customer site.

==== Security ====
Keep in mind that the frontend is exposed to any attack from the wild, deep space in internet. As such, you should take utmost care of any security related settings (you may want to review the ''security'' lesson in your latest advanced training). In particular, as you will never want to allow registrations w/o password on a frontend, make sure to set ''No of Regs w/o Pwd.'' to <code>0</code> (zero) in any frontend PBX configuration.

=== Media-PBX ===

==== Services ====
* The media-PBX needs to have http access to the customer PBXs in order to play e.g. announcements or voice-mails. This is why the HTTP client credentials for URLs <code>http://</code> and <code>https://</code> via <code>paccess@hoster.tld</code> have to be set as explained above.
* The media-PBX, must be configured to have ETH0 (default interface) connected to the ''public network'' and ETH1 connected to the ''hoster network'', this was the tested setup during our tests so it's the recommended configuration.

==== PBX ====
* One PBX-type object per customer. Both ''Name'' and ''Long Name'' set to the ''customer id'', “Number” set to <code>#</code>+''uniq number out of customer id''.
* One Gateway-type object <code>HTTP-EXT</code> with no number. This takes registrations from customer PBXs to for media data
* User-type object <code>MOH</code> with number <code>###10</code>. This is to register the MoH source
* User-type object <code>TONE</code> with number <code>###11</code>. This is to register the <code>TONE</code> interface. Make sure that you cut off the <code>###11</code> in the route to the TONE interface.
* User-type object <code>HTTP-OUT</code> with number <code>###12</code>. This is to register the media-PBX’s local <code>HTTP</code> interface to offload media data such as WQ announcements and voicemail

=== Customer PBX ===
Each customer has a unique ''customer-id'' which is used to derive various names and identifiers (see above). It is derived from (part of) the customer’s name and a sequential number. Something like e.g. <code>Kuenkel00001</code>.

The customer PBX is located within the private part of the PBX hosting provider’s network. Because of this, it cannot send media data to the CPE (which is the end customer’s private network). Media has to be sent via the associated Media-PBX thus, as this is ''dual-homed''.

:* the associated Frontend is used as ''Time Server''
:* ''Unknown Registrations'' is turned on with ''With PBX Pwd only''. This is to enable ZCD (Zero Configuration Deployment) for CPE
:* ''System Name'' set to the customers email domain (even if it is <code>googlemail.com</code> or <code>yahoo.de</code> as it does not need to be unique. Therefore it's necessary to set the customer PBX’ ''Master GK-ID'' property to the value of the media-PBX’ ''System Name'' property.
:* ''PBX Name'' set to the ''customer ID''

==== Handling of calls to MOH, TONE or HTTP-interface ====
As explained in the previous section, the customer PBX cannot send media data to the CPE but must use the respective resources on the associated Media-PBX. Calls to the Media-PBX are routed using GW-interfaces (i.e. Relay) on the customer PBX. Therefore the first step is to register a GW-interface (e.g. <code>GW1</code>) to the <code>HTTP-EXT</code> on the Media-PBX.
=====MOH=====
* Go to PBX/Config/General an enter as "External Music On Hold" the name of a non-exisiting object (e.g.<code>_customer_moh_</code>)
* Go to Gateway/GK an register a GW-interface (e.g. <code>GW2</code>) to this non-exisiting object (e.g.<code>_customer_moh_</code>). The registration will be accepted, in the PBX you will see a PBX-object called <code>_MOH_</code>
* Assuming that you followed the examples before, <code>GW1</code> would be the GW-interface registered at the Media-PBX. In the routing table (Gateway/Routes) configure a route from <code>GW2</code> to <code>GW1</code> and prepend the number used for the MOH-object on the Media-PBX(e.g. <code>###10</code>). The Route in our example would be <code>GW2 -> ###10 GW1</code>
* If you want to play a custom MOH, additionally enter the MOH-URL in the "Music On Hold URL" field(PBX/Config/General). The URL will be retrieved by the Media-PBX, as a result it must be retrievable by the Media-PBX (e.g. 127.0.0.1 in the URL will be the local-host address of the Media-PBX)

=====TONE=====
* to use the TONE interface of the Media-PBX, route calls to the GW-interface registered at the Media-PBX and prepend the number used for the TONE-object on the Media-PBX(e.g. <code>###11</code>).
* since the Media-PBX has only one TONE interface, it will generate the same TONE for all customer-PBX using it. If a customer-PBX needs a different TONE-interface, you have to create am additional Media-PBX.

=====HTTP=====
* the HTTP - interface is needed when an HTTP-URL is retrieved an played as an announcement. The "Extern Name/No" field at the respective PBX-objects (e.g. WaitingQueue) is used to offload the playing of the announcement to the Media-PBX.
* at the customer PBX create a Gateway-type object <code>HTTP-IN</code> with no number. This takes registrations from a a GW-interface (e.g. <code>GW3</code>) at the customer PBXs
* when configuring an announcement URL (e.g. at a WaitingQueue), enter as "Extern Name/No" <code>HTTP-IN</code>. The URL will be retrieved by the Media-PBX, as a result it must be retrievable by the Media-PBX (e.g. 127.0.0.1 in the URL will be the local-host address of the Media-PBX)
* In the routing table (Gateway/Routes) configure a route from <code>GW3</code> to <code>GW1</code> and prepend the number used for the MOH-object on the Media-PBX(e.g. <code>###12</code>). The Route in our example would be <code>GW3 -> ###12 GW1</code>

==== Global Objects in the Customer-PBX ====
===== <code>default</code> Template=====
* ''Config Template''-type object with ''Name'' <code>default</code>
* ''Hide from LDAP'' und ''Critical''
* ''Store Phone Config''
* all check-marks ticked in the ''License'' tab
* the ''Access'' column needs an entry for <code>@</code>''customer.tld'' (this is the ''System Name'' from the PBX configuration) with all check-marks ticked
* within the ''Config'' column, there is only a setting for LDAP Config (''Directories'') as follows:

<code xml>
<phone>
<loc cc='country-code' ac='area-code' ntp='0' itp='00' pbx='subscriber-number'/>
<ldap id='2'
tls='1' port='ldap-port-map-to-pbx-on-sbc, e.g. 9004'/>
<ldap id='3'
enable='1' tls='1' mode='basic'
addr='sbc-ip-address' port='ldap-port-map-to-metadir-on-sbc, e.g. 9007'
dn='PBX Name' pw='??' base='dc=PBX Name'
attr='sn,givenName,company' phone='telephoneNumber:D,mobile:M,:@'/>
</phone>
</code>

'''pw for ldap id 3 is critical: this allows everyone access to the customer directory data via LDAP. If this is not acceptable, the password needs to be removed from the template and configured manually by the end customer'''

==== Configuration of customer related objects in the customer’s PBX and Frontend ====
From an administrative point of view, no configuration specific to the individual device should be necessary for registration of a CPE. The default NetBIOS name (e.g. <code>IP232-01-02-03</code>) is used as registration name thus. This must be used as ''Registration from external'' in the corresponding SessionBorder object thus (for each potential CPE, there must be one SessionBorder object on the associated Frontend, see above).
The registration password used by the CPE and thus the ''Password'' in the SessionBorder object must be set to the ''customer registration password'' (which is specific to this customer, not to the CPE).
The ''Long Name'' as well as the ''Name'' for ''Registration to internal PBX'' in the SessionBorder object (hence the registration name for the CPE set in the customer PBX’s user-type object) is a combination of the ''customer ID'' and a sequential ''customer CPE ID'', e.g. . <code>Kuenkel00001-001</code>. The ''customer CPE ID'' starts with 0 for each customer. This allows for more meaningful data when viewing traces from e.g. the Frontend. Moreover, this scheme allows for nice filtering the object view on the PBX by customer name.
The password to register the SessionBorder objects from the Frontend to the customer PBX is always the globally used ''PBX password''. Hence the ''PBX Password'' check-mark must be ticked in the ''Registration to internal PBX'' area of the SessionBorder object on the Frontend and the ''PBX Pwd'' check-mark in the ''Devices'' area of the user object in the customer PBX. Initially though, no ''Devices'' shall be present in the user object, as this allows ZCD for the CPE.
[[Image:SBC_registration.png|center|thumb|600px|Click for larger image: SBC-registration]]

=== Update Server ===

Tasks:
* Staging (e.g. installation of suitable trust list for HTTPS)
* Firmware update
* Backup of configuration data for CPE and customer PBX
Backup of CPE data is done to the virtual CF card of the customer PBX. Backup of customer PBX data is done to its Frontend.
There is no device or device-type specific update script.
Structure on the customer PBX
<pre>
/DRIVE/CF0/
update/
backup/
backup-mac-date.txt
</pre>

The backup folder on the customer PBX (<code>/DRIVE/CF0/update/backup/</code>) must be set writable but not readable under ''Services/HTTP/Public compact flash access'' so that CPEs can write their backup.

Firmware files are stored on a folder of the associated Frontend. Although this implies that they need to be duplicated to all Frontends, it simplifies the configuration and distributes load.

The generic update scripts are stored in (<code>/DRIVE/CF0/update</code>) on the Frontend. <code>staging.txt</code> is the CPE staging code, <code>update.txt</code> the regular update script. Both scripts make extensive use of [[Reference10:Concept_Update_Server#Setvar_command| update variables]].

Staging proceeds in 3 steps:
* CPE is configured to use the generic hosting staging interface (http://config.innovaphone.com/init) as ''Update-URL''
: This is a publicly available web service, (this service is currently experimental!) relates a requesting device to the hosting provider and customer pbx based on the serial number. If the device can be identified, the update server URL is rewritten to the PBX hosting provider’s appropriate Frontend (based on data that is defined in my.innovaphone). For more information, see [[Reference10:Concept Provisioning].
* CPE executes the Frontend-wide staging script (<code>staging.txt</code>). This performs some init-only tasks
* CPE executes the Frontend-wide update script (<code>update.txt</code>). This performs day-to-day tasks (such as backup)

File structure on Frontend
<pre>
/DRIVE/CF0/
update/
staging.txt - staging script
update.txt - regular update script
global.txt - overrides for global settings
local.txt - overrides for Frontend-local settings
set-customerid.txt - overrides für customer specific settings
staging/ - special staging scripts
global.txt - overrides for global settings
local.txt - overrides for Frontend-local settings
set-customerid.txt - overrides für customer specific settings
dev-IPxxx.txt - device type specific settings
cfg-phone.txt - device class specific settings
cfg-gateway.txt - ditto
firm/ - firmware
nnnnnn/
bootxxx.bin
ipxxx.bin
</pre>

In order to be accessible during firmware updates, the drive (<code>/DRIVE/CF0/update/firm/</code>) must have read (and only read) access on the Frontend under ''Services/HTTP/Public compact flash access''. In order to be accessible from the devices, drive <code>/DRIVE/CF0/update</code>) needs to be readable (and only readable). Both can be achieved with a single <code>/DRIVE/CF0/update/</code> entry.

Assigning the initial update URL (<code> http://145.253.157.5/redirect.php </code>) to CPE is for further study. It can be done as usual (DHCP), but this requires co-operation by the end-customer which may be a problem. Of course it can also be pre-configured by the hosting provider. In the latter case, the URL must be configured to the device after any long reset (factory settings).

===== Update Script Security =====
Update scripts may include registration password (although encrypted) to facilitate automatic registration with almost no user intervention (cf. set-''customerid''.txt above). By definition, staging scripts are readable by everyone (as they are used to configure otherwise unconfigured devices, so no kwowledge of credentials can be assumed). There is no easy way around this. One option would be to define a password for the web site hosting the scripts. This would then imply that the password needs to be configured to the CPE, which is undesirable from an administrative point-of-view. Moreover, with innovaphone gear (that is, when a web server internal to an innovaphone device is used), the only way to secure the scripts with a password would imply to use an admin account and password – clearly unacceptable from a security point-of-view.

To secure the update scripts, a mechanism based on innivaphone's device certificates must be employed. See [[Reference10:Concept Provisioning]] for more details.

==== Deployment ====
===== Initial =====
Create once-only services
* Kerberos and Kerberos Backup
* Create a new account for the PBX hosting provider in my.innovaphone (if the generic staging is to be used, see above)

===== Shared Services =====
Create services shared by a set of customers:
* Frontend
* Media-PBX
* Metadir
* Reporting LinuxAP
* Fax Linux-AP
* copy update/staging scripts (global.txt, cfg-*.txt, dev-*.txt) tot he Frontend drives (those are identical on all Frontends)
* create appropriate local.txt on Frontend

===== New Customer =====
* create IPVA with customer PBX
* create appropriate <code>set-</code>''customer-ID''<code>.txt</code> on Frontend
* create appropriate user objects on customer PBX as well as corresponding SessionBorder objects on Frontend
* create project for customer in my.innovaphone, set ''URL'' to the PBX hosting provider’s <code>staging.txt</code> on the appropriate Frontend (e.g. https://212.124.38.120/DRIVE/CF0/update/staging.txt) and the encoded public key of the hosting providers RootCA as ''Trust'' (as taken from a config file)

===== CPE =====
* Add device tot he customer project in my.innovaphone
* factory reset (optional, of course)
* set <code>http://145.253.157.4/redirect.php</code> as ''Command File URL'' in ''Services/Upate''
* wait for or force poll
* CPE registers with the Frontend and customer PBX as <code>_UNKNOWN_</code>

=== On-Site (Customer) Support / Debugging ===
==== Alarms and Events ====
* Alarms, events should be saved centrally on the Frontend, this way the admin has a full picture of all events and syslog in a Frontend-cluster. The CPE devices are configured by the staging script to send their events/alarms via HTTPS to the Frontend server.
** incoming Alarms/Events should be authenticated by the Frontend server, the CPEs must be configured (during staging) with the appropriate HTTP-client credentials. The account used for the HTTP-login must be configured with ''Viewer'' rights on the Kerberos - server.
** the received Alarms/Events can be further forwarded by the Frontend server to a Syslog-server. The received events can be then written in a database/text-file and used for further evaluation.
** the local event and alarm list is always kept in local Flash memory. The number of entries to keep can be configured in the Services/Logging tab. Since your Frontend-Server should not generate a large amount of events/alarms, you can use the default values(last 50 local events are stored in Flash memory).
==== Syslog ====
* the CPEs should not create logs, all relevant information(i.e. state of user-registrations) is retrieved from the Event/Alarm-list
* IPVAs(e.g. customer PBX) should generate logs and store them locally on their CF-card
** the recommended Syslog settings are ''PBX calls'' and ''Gateway calls''
** depending on the amount of generated logs (i.e. the size of your Customer PBX), the [[Reference9:Services/Logging | Max File Size]] should be set accordingly. You should capture at least 4 days of log information(e.g. allowing to inspect log information created before a weekend)
* if its required that CPE devices generate logs, it will be necessary to store the log-information on a central server(e.g. Frontend server). However incoming Logs cannot be authenticated by the Frontend server, since this function is not implemented in the innovaphone LOG-server. If incoming Logs should be authenticated, a Linux-AP should be used as central Log-server (the Linux-AP offers the possibility to authenticate incoming logs)
==== Config backup ====
* Phone configuration is backed up to the customer PBX CF, using the Update Server mechanism.
* the configuration of devices in the Hoster-network( e.g. Media-PBX, etc.) are saved on the CF-card of the Frontend-server

====Accessing the web-interfaces of devices====
* All devices (including CPE) have joined the Kerberos domain. As a result, all administrators are able to log in (provided they have access to the customers network, TeamViewer is an option)

=== Reporting (Multiple PBX) ===

NEEDS TO BE UPDATED (TLE)

The LinuxAP VM for reporting needs to have quite a large CF to be able to store all CDR data for a reasonable time period.

* VMWare disk size should be 50GB initially. This is based on a rough estimate of 200 customers and a time frame of 1 year
: rough estimate. Time will tell
* RAM 1GB

==== Naming Conventions ====

To grant access for customers (and reseller) to the Reporting login page (https://Reporting-IP-Adress/apps/innovaphone-reporting/user/login.php), it's nessesary to create a cdr filter called "base filter" and a user login which is bound to this base filter.
These logins and filters can only be edited and created by the hoster (i.e. cloudkom).
Since the customer can't change his credentials we use the "customer ID" and the "customer registration password" for further steps.

As we mentioned in chapter [[#Customer_PBX|Customer PBX]] each customer needs a uniqe PBX name, but different customers may share the same "System Name".
For this reason it's nessasary to set the Grouping-ID in the Reporting application to ''PBX Name'' (as set in ''Config/PBX'').
Never change this setup because filters are depending on the Grouping ID!

'''Filter parameters for customers:'''

* Base Filter: <leave it empty>
* Filter Name: ''customer ID'' (which is the ''PBX Name'', i.e <code>Kuenkel00001</code>)
* PBX Name: ''customer ID'' (which is the ''PBX Name'', i.e <code>Kuenkel00001</code>)

'''User configuration for customers:'''

* Name: <customer ID>
* Password: ''customer registration password''
* Base Filter(s): ''customer filter name''

For reasons of billing (or whatever) it could be fine for resellers to have a filter for all of -his- sold PBXs

'''Possible filter parameters for reseller:'''
(in fact, the reseller id is a customer id, because the only difference is the filter content)

* Base Filter: <leave it empty>
* Filter Name: ''reseller ID'' (i.e. innovaphone00001)
* PBX Name: ''customer ID'' +
* PBX Name: ''customer ID'' +
* PBX Name: ''customer ID'' ...

'''User configuration for reseller:'''
* Name: ''reseller ID''
* Password: ''reseller registration password''
* Base Filter(s): ''reseller filter name''

====Konfiguration Reporting ====
* Grouping ID: PBX-Name
* Create filter and user logins for the customer
* LDAP?
* Report Mails?

====Konfiguration Kunden-PBX ====
===== Gateway / CDR0 =====
* ''Type'' <code>Remote-AP-S</code>
* ''Address'' ''Reporting Linux-AP IP address''
* ''Port'' <code>443</code>
===== PBX / myPBX / Call List Service =====
* ''Type'' <code>Remote-AP</code>
* ''Host'' ''Frontend-IP-addr:HTTPS-Portmap-on-Frontend-to-Reporting-App''
* ''User'' <code>innovaphone-reporting</code> ?????
* ''pass'' <code>reporting</code>

In contrast to the CDR0 interface, the Call-List-Service doesn't offer the possibility to choose the ''Type'' <code>Remote-AP-S</code>. The myPBX client decides which protocol to use (HTTP or HTTPS) depending on the URL (http or https)used to connect to the PBX. So if myPBX uses HTTPS to connect to the PBX, it will use also HTTPS to connect to the Reporting-App.

=== Fax Server ===

NEEDS TO BE UPDATED (afI)

A LinuxAP VMware disk size of 50GB should be sufficient. Configure the size of the virtual drive before starting the Linux installation for the first time.

Since the FAX-Interface must be reachable from the public network, it must be offloaded from the Customer VM to the Media Gateway. The SOAP connection from the Faxserver application will be still directed to the Customer VM/PBX.

[[Image:Routing_fax.png ]]

On the customer VM we have to configure a Gateway Object and routes to and from GWxx which is registered on the Media Relay instance. We reuse HTTP-EXT registration at this point to send Fax calls to Media.
====Customer PBX Settings for Faxserver====
** Gateway Object Name= <code>Fax</code>, Number= <code>some prefix number used for Fax extensions</code>, Option "Prefix" activated
** add the Gateway Object to the SOAP/TAPI group, in order it is visible for SOAP applications connecting to this PBX
** Prepare User Objects for Fax usage:
*** Fax License must be assigned
*** E-Mail must be configured and must match the sender address

====Customer Gateway Settings for Faxserver====
** Fax GWxx, Register as Gateway, 127.0.0.1, Name= <code>Fax</code>
** Route GWxx (Fax) --> ###13 GWyy (HTTP-EXT)
** Route GWyy (HTTP-EXT) --> GWxx (Fax)

For multiple customer PBXes we define a single Gateway with FAX Interface:

====Media PBX====
** Gateway Object Name= <code>fax</code>, Number= <code>###13</code>

====Media Gateway====
** Interface FAX, Internal Registration, 127.0.0.1, Name= <code>fax</code>, Coder G711,20 , "Enable T.38"
** HTTP-Client must be configured to use [[Howto:Hosting#Kerberos_User|credentials for programmatic access]] to be able to read and write to WebDAV Server on LinuxAP with Faxserver application.

====Faxserver Instance====

For each Customer VM an own Faxserver instance on the LinuxAP must be configured (one LinuxAP, multiple Faxserver instances for every Customer).

** SOAP connection must be configured to point at the PBX running on the Customer VM
** E-Mail Account configuration is important to be able to deliver E-Mails to the Faxserver via SMTP
*** The E-Mail account, configured at the Faxserver instance, will be used at teh Customers Mailserver to authenticate against the Mailserver on Faxserver

==== Mail to Fax Gateway ====
Für Kunden, auf deren POP3 Server aus Cloudkom Netz nicht zugegriffen werden kann, wird ein SMTP Server auf Basis von IP-AP aufgestellt. Dort können die Kunden dann per E-Mail die Faxe anliefern. (<mantis-issue id=89710/>)

Use Case "Fax verschicken":
*Kunde schickt aus dem E-Mail Programm ein Mail mit PDF-Anhang an z.B. <code>+497031730099@fax.cloudkom.com</code>
*Rufnummer für Zielfax muss im User Part der To: Mailadresse stehen (im Beispiel ist es +497031730099)
*Das passende Postfach für Fax Server des jeweiligen Kunden wird anhand der From: Mailadresse bestimmt.

Damit die From: Adresse nicht gefaked werden kann, werden nur authentifizierte SMTP-Verbindungen zugelassen. Der Kunde muss dazu bei sich im Exchange einen "SMTP Send Connector" für die Domäne fax.cloudkom.com einrichten ([http://msexchangefaq.de/connector/sendconnector.htm]) mit Basic Auth over TLS.

Als SMTP-Server kann man ein Postfix mit Postgresql Erweiterung nehmen, damit man die Kunden Daten (Domains, Postfächer, Logins) direkt aus der Fax Server Datenbank lesen kann.

Als POP3-Server (damit Fax Server die Mails lesen kann) wird dann Dovecot eingesetzt.

Beschreibung der Implementierung: [http://wiki-intern.innovaphone.com/index.php?title=E-Mail_Fax_Server_Gateway_(Project_Cloudkom) E-Mail_Fax_Server_Gateway_(Project_Cloudkom)].

=== Directories ===
There are 2 services provided to customers:
# the PBX directory
# an optional company-wide directory (external LDAP)
==== PBX Directory (extensions) ====
* one NAT port map is to be created per customer on the Frontend for port LDAPS (TCP source port xxx to target Port 636)
:This port can be used in the phone’s ''Port'' field in the ''PBX'' area in ''Phone/User/Directories/PBX''. The PBX LDAP server’s IP address is implied from the registration data. This way, the CPE will in fact access the customer PBX’s LDAP server as opposed to the Frontend’s one
* LDAPS can be used safely, as the CPE’s LDAP client does not verify the certificate anyway (although it would be trusted as it is derived from the PBX hosting provider’s RootCA)

====External Directory ====
=====Estos Metadir=====
*there is one Metadir server per Frontend which serves all customers associated with this Frontend. Hence there is one inbound NAT port map that maps one port to the Metadir server’s LDAPS port. This map is used from all customers. Customer specific directories are implemented as logical views in the Metadir LDAP server, not as separate servers
*there is thus one distinct LDAP node (dc=''customer-ID'') per customer
* there is also one distinct replicator for each customer (which is used to import the customers directory data in to the Metadir)
**Replicator
*** The customer would provide its contact database as „comma separated CSV (Windows)“ file (e.g. as exported from Outlook)
*** The file must have the columns ''"Surname","Firstname","Company","Busines Phone ","Mobile Phone"''
*** All numbers must be in E164 format, e.g. +49703173009123
*** File name is <code>contacts.csv</code>
*** The file is uploaded to the Frontend’s CF-file system
*** Each customer has its own directory (<code>https://212.124.38.120/DRIVE/CF0/directory/</code>''customer-ID'') on the Frontend. This is the place <code>contacts.csv</code> has to be uploaded to. For this to work, the path must be set to write-only on the Frontend!
*** Customers can use e.g. [http://curl.haxx.se/dlwiz/?type=bin&os=Win32&flav=-&ver=2000%2FXP curl]. Syntax: <code>curl --verbose -k https://212.124.38.120/DRIVE/CF0/directory/customer-ID/ -T contacts.csv</code>. Note that standard WebDAV clients will probably not work due to the fact that this directory is write-only.

Structure on Frontend
<pre>
/DRIVE/CF0/
directory/ - write-only w/o authentication
customer-ID/
contacts.csv
</pre>
* Metadir has a duplicate of the Frontend’s directory structure
<pre>
C:\directory\
script.bat - script that retrieves customer directory data <code>contacts.csv</code> from the Frontend, called by replicator
contacts.csv - sample
customer-ID\
contacts.csv - customer data
</pre>
* Metadir’s per-customer replicator imports the local contacts.csv when run. Before doing so, it calls script.bat which retrieves the appropriate contacts.csv from the SB (this behaviour needs to be configured in Metadir, ''Database Wizard'', '' Zusätzliche Anwendungen(additional applications)'').
: script.bat copies the then-current customer’s contact.csv from the Frontend using curl (curl - syntax: <code>curl --verbose -k -u user:password https://10.30.255.0/DRIVE/CF0/directory/%1/contacts.csv -o c:\directory\%1\contacts.csv</code>
: user:password in script.bat are administrator credentials valid on the Frontend (as contact.csv files are read-only, see above)
* Each replicator will be run every 3 hours
: The replicator can also be triggered from the cmd-line (calling e.g. <code>TextReplicator.exe </code> as found in the Metadir installation directory. Start a replicator from the GUI and have a look at lastreplicator.bat in the install directory). This may be useful if the PBX hosting provider has implemented a user portal to upload the contact data.
* The replicator is created using the ''Replicator-Wizard'' and associates the .csv columns to the respective LDAP attributes/DB field names. A combination of all attributes is used as primary key
: [[Media:Cloudkom-Metadir-Replikator.png | Replicator Overview]]
*LDAP-nodes:
** LDAP node access authentication is based on distinct, per-customer users, username (=''customer ID''), password(=''customer registration password''). No IP address restriction is used.
** profile is ''Default'' always, no customer specific profile is required (this is handled using the phone’s ''Dialing Location'')
** [[Media:metadir-LDAP-Knoten-config.png | Settings]] can be seen in the screenshot
Here is how to export contact data from Outlook 2010:
** as far as we know it is only possible to export your own contact list. In case that all users use a global contact list, this list has to be copied first into your own contact entry list.(select [Global List](e.g. IP Kontakte) -> right click -> copy -> choose own contacts)
** From Outlook ''File -> Open -> Import -> Export to file -> comma separated values (Windows) -> (select contact folder) -> "Map custom fields"(german: Benutzerdefinierte Felder zuordnen) -> choose "Surname","Firstname","Company","Busines Phone","Mobile Phone"-> Finish''
*LDAPS
** Just any certificate will do on the Metadir, as the LDAP client does not validate the certificate
** Metadir uses port 714 for LDAPS, Frontend needs an appropriate NAT Map
=====LDAP-Client=====
* directory settings should be set in a PBX ''Config template''-type object in the customer PBX and applied to all user objects there
: [[Media: Cloudkom-Metadir-Ldapclient.png | Phone/User/Directories/External LDAP Server Settings]]
: ''Dialing Location'' settings need to be done according to the customers trunk line settings
=====myPBX=====
* external directory lookups for myPBX are done by the PBX rather than by the myPBX client itself. The directory configuration is taken from the users phone configuration (as stored in the PBX). This of course presents a problem as the phone configuration will use the external Frontend NAT map data for the Metadir, whereas the PBX itself – sitting in the PBX hosting providers private network – needs to use Metadirs private address. There is a special configuration parameter for the PBX which sets the LDAP configuration used for any directory lookup performed for myPBX:
: <code>config add PBX0 /ldap-default-addr local-ip-addr-of-metadir /ldap-default-port 714</code> (714 is Metadirs LDAPS port)

=== Voicemail ===
Voicemail is run on the customers PBX as usual. However, as discussed before, the Webmedia (a.k.a <code>HTTP</code>) interface on the media PBX must be used. VM xml script and recorded voice mail files are stored on the customer PBX’s CF card as usual though. The trick is to have a registration to the customer PBX’s voice mail object. If this is present, voice mail will use this registrations to terminate media data rather than the local Webmedia (which is the default).

The registration on the local VM object needs to connect calls to the remote HTTP interface on the media PBX. This is implemented using a GWx interface in the customer PBX’s gateway level which registers to the VM object. There is a route from this GWx to the GWy which in turn registers with the media PBXs <code>HTTP-EXT</code> object (there are no calls to the VM object ever).

==== PBX ====
* voicemail-object
** Hardware-ID = <code>vmrelay</code>
** Script-URL (installed on local CF Card as usual) = <code>https://customer-PBX-IP-address (not 127.0.0.1!)/DRIVE/CF0/vm-de/vm.xml?$_divconn=false</code> (this URL will be evaluated on the media PBX, this is why 127.0.0.1 will not work!)
** suitable extension depending on customers numbering plan

==== Gateway ====
** vmrelay GWxx, Register as Gateway, 127.0.0.1, Name= <code>vmrelay</code>
** Route GWxx (vmrelay) --> ###12 GWyy (HTTP-EXT)

==== MWI ====
Simpkly works as is.

==== Mail MWI ====
Mails are sent through the PBX hosting provider’s own mail server. This may require authenticated SMTP. This needs to be configured in each <code>email.xml</code> in the customer PBX’s voice mail installation:

* message sender
* Subject of MWI mail
* mail server
* credentials

Apart from the mail subject (which is language dependant), this is identical for all customers, so it can be done once and copied then.

User Email addresses must currently be set in each user object’s ''URL'' attribute (or in a separate file in the user directory).

=== Operator ===

to be updated

innovaphone Operator v10 can be installed in local client location and connects directly to client IPVA using HTTP-SOAP connection using the same Port used for HTTP management defined on the SBC.

All SOAP communication goes through this HTTP connection so all features will be available and working properly. The LDAP configuration of the Operator v10 is similar to the one performed in the IP Phones.

=== Mobility ===

Mobility needs access to DTMF tones and thus to the RTP media stream. As the customer-PBX has no public IP address, again, the media for all mobility calls must be routed through the media-PBX linked to the customer PBX.

In the media-PBX, we need a ''media-relay-loop'' gateway-type object (no ''Prefix'' check-mark ticked) with a gateway GWx interface registered to it. On the media's gateway level, there is a route that routes calls to this interface directly back to that interface. This GWx interface used must have the ''Media-Relay'' check-mark ticked. Calls to the media-PBX's ''media-relay-loop'' object are thus echoed straight back to the PBX. However, the media-stream will be terminated on the media, so that it is available from the media's public IP address.

On the customer-PBX, a gateway-type object is created that sends calls to the media's ''media-relay-loop''.

For incoming mobility calls to work, they must be recognized within the gateway level (that is, the mobility object's extension must be known) and routed through the aforementioned media-loop before it ends up in the client-PBX's mobility object.

For outgoing calls, the fork destination must be set such that the outgoing mobility calls are first sent through the media's ''media-relay-loop'' before they end up in the client PBX's trunk.

=== DECT ===

to be updated

=== Backup ===
''Disaster recovery'' backup ist o be done by the operator of the VMware infrastructure.

User data (PBX config, CPE configuration) is backed up by the update server as outlined above.

=== UI/Portal ===
Innovaphone does not supply a dedicated UI for hosting scenarios (neither for the PBX hosting provider nor for the end customer). It is envisaged that hosting providers will craft their own tool for this, as this is highly related to the provider’s business model.

===Special scenarios===
* Customer-setups where the phones are in separated private networks, e.g. home-office without VPN to LAN of main-office. In this case the phones in different private networks can not send RTP-packets to each other. To overcome this problem, the media-relay option at the SessionBorder object must be enabled for those SessionBorder objects that have registration from "foreign" networks. If the Frontend is used as RTP-endpoint(i.e. by activating the media-relay option), the UDP-RTP port-range(by default 16384 / 32767) must be configured.

===Limitations===
* Customers-setups with Master-Slave PBXs are not supported. The problem here is that the Master & Slave PBX are within the hosting provider’s private network and some PBX mechanism (e.g Registration-Redirection, Soap) would return IP-addresses with IP-addresses from the provider’s private network to device at the customer site. (e.g. a phone registering at a PBX might get an indication to register at another PBX - however the IP-address in this Redirection is in the hosting provider’s private network, therefore unknown to the phone).

= Related Articles =
[[Howto:A rough estimate of IPVA Performance]]

Howto:Hosting with V10

2014-01-25T13:46:01Z

Ole: /* Configuration of customer related objects in the customer’s PBX and Frontend, new figure */

This document describes general recommendations for setting up a „hosted PBX“-environment. It is based on a reference implementation done early 2013. Everything said in this article is merely a recommendation and you may deviate from it for real-life projects. However, it may still serve as a guideline of “what to think of”.

There are no specific configurations given throughout the article. As such, it targets an iCE with some decent knowledge about innovaphone products as an audience.

This article is still “work in progress”.



=== Overview ===
Each customer receives a dedicated PBX (best run as IPVA). So no “dynamic PBX”s are used. Each customer has exactly one such PBX. So no Slave- (as they do not seem to make sense) and no Standby-PBX (as this is better implemented using VMware tools such as High Availability or Fault Tolerance). This article does explicitly not deal with mixed environments where some PBXs are hosted and some on-premise.

Further services (apart from the basic PBX) such as e.g. fax are provided by multi-tenant capable applications. How many customers and/or users (i.e. extensions) can be served by a single such application is for further study. However, from an administration point-of-view, it seems to be easier calculating the same application-server to number-of-customers ratio for all the applications, as it allows organizing the whole setups in clusters where a specific set of customers is associated to a specific set of application servers.

In a real-life setup, there may or probably will be a central management server which may run software to simplify the management of the whole setup as well as provide an end customer portal. This server, called ‘’Management Server‘‘ in the overview graph is thought to be specific to the PBX hosting provider and is thus – although it has an important impact – not discussed in this document.

[[Image:Cloudkom-grobuebersicht1.png]]

Most of the hosted services, as well the customer-PBXs and the shared services, will be located in a private network run by the hosting provider. This is to make sure they cannot be easily attacked and also to save on publicly available IP addresses (which may be a scarce resource). As a result, from a TCP/IP point-of-view, these services are not reachable from the customers own private network. Also, to save on resources and reduce complexity, no VPN is set up between the customer and the hosting provider. To implement the required customer access to these services, there are 2 extra services which need to have an additional external IP address (“dual homed”). These are called “Frontend” and “Media-PBX”.

The Frontend provides:

* Proxy registration of customers terminal devices (e.g. phones) located on premise to the customer PBX
: Terminals in fact register with the Frontend which in turn entertains a proxy-registration to the customer PBX for each endpoint
* inbound NAT with port maps for selected protocols (such as e.g. HTTPS/443 und LDAPS/636,714)

The Media-PBX

* provides a reachable media endpoint for media data provided or consumed by services within the hosting providers private newtork
: This includes e.g. ''music on hold'', locally generated calling tones, Voicemail, multi-party conferences and fax
This architecture ensures that the hosting providers network topology is invisible to 3rd parties (including possible attackers). Furthermore, the hosting provider only needs 2*n+1 public IP Addresses (where ''n'' is the number of ''shared service'' groups).
The “dual homed” gateways must be configured to have ETH0 (default interface) connected to the ''public network'' and ETH1 connected to the ''hoster network''.
[[Image:Cloudkom-netzuebersicht1.png]]



==== SIP Provider ====
Each customer has its own SIP trunk, configured on the according customer IPVA. The SIP trunk must be configured without using MediaRelay. As a result, if a customer makes a call to the PSTN(SIP provider), the RTP-stream goes end-to-end - between the SIP-provider and the phone at the customer site. Since the customer phone is behind a NAT router, the SIP provider must support NAT traversal.

In general a [[:Category:3rdParty SIP Provider|certified SIP-provider]] can be used, if the provider passed the interop-test for [[Howto:SIP_Interop_Test_Description#NAT_Detection.28Important.29 | NAT Traversal]], [[Howto:SIP_Interop_Test_Description#Fax_using_T.38.28Important.29 | T.38]], [[Howto:SIP_Interop_Test_Description#Reverse_Media_Negotiation.28Important.29 | Reverse Media Negotiation]] and doesn't require MediaRelay to be enabled.

==== Passwords ====
Throughout the system, a number of passwords are used in various places. It is critical to use as less passwords as possible to make day-to-day administration easy and as much passwords as necessary to keep things secure. So here is an overview:

* Admin passwords
: Admin user authentication is based on Keberos. Each admin thus can and should have individual accounts and passwords (referred to as ''individual admin password'')
: all devices shall have a "local admin" passsword which should be kept secret and not be known by normal administrators and should normally never be used. This is referred to as ''system-wide admin password''
* PBX passwords
: PBX passwords needs to be the same in all oft the hosting providers PBXs (and do not need to be typed-in anywhere except during a PBXs initial configuration) . The are referred to as ''PBX password''
* Object password. There are 2 kinds:
** Passwords, which need to be known to the customer. Registration passwords for terminal devices would be an example. Those are referred to as ''customer registration password''). Another example are initial passwords for myPBX (that is, user passwords). They are referred to as ''customer login password''. For each customer (not for each line), a distinct ''customer registration password'' is defined, which normally never changes. Furthermore, another ''customer login password'' is generated, which is used initially for all user objects but will be changed by the end users.
** Password which are not disclosed to the customer. These are used for internal registrations, e.g. a local interface or gateway registering at the customer PBX. For this, the '' pbx password'' will always be used
* Kerberos DB password
: The ''PBX password'' shall be used for encryption of the Kerberos database (as it does make no sense to use a different password here)

Unfortunately, the Linux AP has no support for Kerberos so separate admin password are required. We distinguish passwords used during daily administration and those which are not.

* Linux Admin password
:this is the password used in day-to-day administration, referred to as ''Linux Admin password''. It is used as ''web server credentials'', ''webdav access credentials'', ''application access credentials'', 'innovaphone Reporting access credentials'', ''innovaphone Fax access credentials'' etc.
* Linux System password
: the password that is used as ''root credentials''. For this, the ''PBX password'' shall be used
: The database passwords (e.g. ''postgresql admin password'') can be left as by default, as the DB server is accessible from 127.0.0.1 only anyway

==== Customer-ID ====
Each customer should have a unqiue ''customer id''. It should be “safe” (that is, no umlaut, no spaces, no obscure special characters). Something like e.g. <code>Kuenkel0001</code> will do.
==== NTP ====
All devices require correct time setting. They all must have be a working NTP time source configured (and probably also a working alternate).

The ''dual-homed'' devices (see above) shall use 2 reliable time sources (either run by the hosting provider or from the internet). All other devices shall use "their" own Frontend as NTP Server (a backup time source is not strictly required here as these devices are anyway unusable for customers when the Frontend is down).

=== Certificates ===
The entire HTTP and LDAP traffic from and to the customers network is encrypted. This affects for example a customers access to the PBX (e.g. if the customer is granted (limited) access to the PBX config or for myPBX), as well as access to the reporting service.

To facilitate access to these devices without any warnings issued by the clients (e.g. browser security alerts) all devices require suitable certificates (that is, the host name and IP address must be noted in the certificate and they must be derived from a single signing authority so that end-users only need to import a single root certificate in order to accept all of these device certificates.

The devices built-in certifcates cannot be used as they only refer to the devices NetBIOS name (e.g. IPVA-a8-5a-38) which will not be used to access the devices. Also, in the case of IPVA, the default certificate is self-signed as opposed to being derived from the aforementioned uniform root certificate.

To derive device-certificates which all inherit from the same root certificate, a so-called ''RootCA'' is needed.

There are multiple ways to implement this. Although there are better schemes available, one way to do it that requires no 3rd party gear is to generate a RootCA (in ''General/Certificates/RootCA'') on a dedicated IPVA. This RootCA then can be used to generate all of the other certificates. They are stored in the IPVA’s virtual CF card (<code>/DRIVE/CF0/CA/certs/</code>) and can be exported to the other devices from there.

==== RootCA ====
For the RootCA, we use the IPVA that also implements the central Kerberos server. Unfortunately, with the current firmware each generated device certificate will also replace the IPVA’s own device certificate. This is of course somewhat unfortunate, however, it is not really an issue as no end-customer will ever access the Kerberos IPVA anyway. The Kerberos server itself does not rely on the device certificate.

You first generate a RootCA on the RootCA-IPVA ('General/Kerberos''). The following data must be used:

C=''your-country (e.g. Germany) '', O=''hoster'', CN=''hoster'' Device Certification Authority, Key-length 4096, lifetime 20 years

This new RootCA (which is now the IPVA’s device certificate) needs to be trusted on the IPVA (''General/Admin'').

==== Device Certificates ====
To create individual device certificates, use the RootCA created and use the following data:

Key 4096, Common Name=''devices NetBIOS Name, Organization=''hoster'', Country=''your-country (e.g. Germany) '', DNS Name 1=''devices external IP address'', DNS Name 2=''devices internal IP address'', IP Address 1=''devices external IP address '', IP Address 2=''devices internal IP address ''

For devices with an internal IP address only, it is important to specify the IP address of the NAT router used to access the device as external IP address (e.g. for a customer PBX, this will be the Frontend used). You specify the IP address only, not the port map.

If you intend to assign real DNS names to your devices, you may of course specify these as ''DNS Name 3'' too.

In order to be able to export the new certificate to the target device, you need to make sure you tick the ''Backup on CF'' check-mark, so it is saved on the CF as ''serialno''<code>.pem</code>. To transfer the new certificate to the target device, take note of the serial number and download the respective certificate file from <code>/DRIVE/CF0/CA/certs/</code>''serialno''<code>.pem</code>. This file can then be uploaded to the target device (''General / Certificates / Device certificate / Upload'').

==== Browser Installation of the Root Certificate ====
To get rid of the browser security alerts when accessing devices with e.g. HTTPS, the public key of the root certificate must be trusted by the browser. For this, it needs to be exported in to a file (you can best do this from the RootCA’s trust list in ''General/Certificates/Download/PEM'' into <code>certificate.crt</code>).

It must then be imported to the browser. This needs to be done once by both administrators and customers.

'''Firefox'''
* ''Extras / Einstellungen / Erweitert / Zertifikate anzeigen / Zertifizierungsstellen / Importieren''
* import the .crt file
* tick ''Dieser CA vertrauen, um Websites zu identifizieren''

'''Internet Explorer'''
* ''Extras / Internetoptionen / Inhalte / Zertifikate / Beabsichtigter Zweck Clientauthentifizierung / Vertrauenswürdige Stammzertifizierungsstellen / Importieren''
* import the .crt file

=== Kerberos ===
Kerberos is used to implement authentication for all devices. This includes both devices in the PBX hosting provider’s infrastructure and the CPE. For this to work, all devices must subscribe to the Kerberos realm. The PBX hosting provider’s DNS domain (e.g. ‘’hoster’’<code>.tld</code>) should be used as Kerberos domain name. This way, Kerberos can be found using DNS SRV records.

The IPVA used as RootCA can be used as master kerberos service too. A stand-alone Kerberos server (that is, the one that is implemented in the ''Gateway'' level) is being used. The (probably limited) number of admin accounts is maintained manually.

In fact, if the PBX hosting provider uses an active directory service to manage employee accounts, an AD-replicated PBX run on the central Kerberos IPVA is also a viable option.

Either way, a standby Kerberos server should be setup as a separate IPVA and can be replicated from the master kerberos as usual.

Unless an active directory is used, no trust relationships are required. If so, the ''system-wide admin password'' should be used as shared secret.

The devices which rely on kerberos for authentication (that is, all devices!) locate the Kerberos servers using DNS SRV records. Devices within the hosting provider’s private network use the internal IP address for this; external (e.g. CPE) devices use their respective Frontend. For this to work, each Frontend needs some UDP NAT maps as follows:

<pre>
Protocol Port Address Int. Port
UDP 7465 kerbhost-dup 464 delete
UDP 7464 kerbhost 464 delete
UDP 7089 kerbhost-dup 88 delete
UDP 7088 kerbhost 88 delete
</pre>

Instead of relying on the PBX hosting provider’s DNS server, the SRV records can be set in the devices during staging. This way, each device can be configured to use its associated Frontend only:

<pre>
config change DNS0 /a-name kerberos1i.#(h-domain)
/a-addr #(h-kerberos1ip) /a-name kerberos2i.#(h-domain)
/a-addr #(h-kerberos2ip) /a-name sbc#(h-sbcindex).#(h-domain)
/a-addr #(h-sbcextip)
/srv-name _kerberos._udp.#(h-domain) /srv-target kerberos1i.#(h-domain) /srv-port 88 /srv-prio 0 /srv-weight 0
/srv-name _kerberos._udp.#(h-domain) /srv-target kerberos2i.#(h-domain) /srv-port 88 /srv-prio 5 /srv-weight 0
/srv-name _kerberos._udp.#(h-domain) /srv-target sbc#(h-sbcindex).#(h-domain) /srv-port 7088 /srv-prio 10 /srv-weight 0
/srv-name _kerberos._udp.#(h-domain) /srv-target sbc#(h-sbcindex).#(h-domain) /srv-port 7089 /srv-prio 12 /srv-weight 0
/srv-name _kpasswd._udp.#(h-domain) /srv-target kerberos1i.#(h-domain) /srv-port 464 /srv-prio 0 /srv-weight 0
/srv-name _kpasswd._udp.#(h-domain) /srv-target sbc#(h-sbcindex).#(h-domain) /srv-port 7464 /srv-prio 10 /srv-weight 0
</pre>

With this setup, all devices will prefer the internal IP addresses. External (e.g. CPE) devices will of course not be able to reach these internal addresses, but they will succeed with one of the Frontends. Thus CPE devices will use any of the available Frontends, not necessarily their own. This will work as all Frontends ultimately NAT to the same Kerberos server.

Note: The ''_kpasswd._udp'' SRV entry should point only to the primary Kerberos Server (i.e. either external NAT-map or internal IP-address), since the ''_kpasswd._udp'' is used to join devices to the Kerberos-Realm. It is only possible to join a realm on the master-Kerberos server, not on the standby. As a result, if the Master-Kerberos server is down, it is not possible to join/unjoin device to the Kerberos-Realm.

==== Kerberos User ====
In addition to the accounts for the administrators, there must be a service account <code>paccess</code> used for programmatic access to the devices. This will for example be used by the Metadir server to access the Frontend (and can also be used by a hosting provider specific administration software). In addition to that, this account is to be configured under ''Services/HTTP/Client'' for URLs <code>https://</code> and <code>http://</code> on the Frontend, Media-PBX and customer PBXs. This allows all these device to access all other devices using HTTP/S.

The credential for this account need to be kept securely, as they allow admin access to all devices in the infrastructure!

To facilitate automatic join into the kerberos domain during staging, there needs to be an additional special account with ''Join Realm'' rights only: : <code>joiner, joiner</code>. This account is not particularly relevant from a security point of view, as aside from adding or removing devices from a realm nothing relevant can be done on behalf of it.

=== Licenses ===
It is in the PBX hosting provider’s best interest to implement a centralized license management. A central licensing server instance is needed thus. This can be run on the master and standby Kerberos server. All licenses purchased by the PBX hosting provider are installed here. The license server runs a PBX. The only task for this PBX is to host the licenses and distribute them to the Frontend and Media PBXs, which are registered as ''License only'' slaves and will further distribute the licenses to the customer PBXs (which are in turn registered as ''License only'' slaves to their respective Media-PBX).

If you choose to use a PBX based Kerberos server (see above), this same PBXs can be used.

The license server PBXs will have the PBX hosting provider’s domain name as ''System Name'' (e.g. <code>hoster.tld</code>) and <code>.</code> as ''PBX Name''.

=== Frontend ===
The Frontend

* accepts external registrations from customer CPE
* provides a central (virtual) CF-card storage for non-sensitive data (e.g. firmware files)
* supports mutliple customer PBXs. The exact number is yet ffs., however, we estimate no more than 135 currently. Frontends will simply be numbered (<code>sbc1</code>, <code>sbc2</code> etc.)
* The Frontend being a “dual homed” gateway, must be configured to have ETH0 (default interface) connected to the ''public network'' and ETH1 connected to the ''hoster network''.

==== NAT ====
* The Frontend will provide inbound NAT mappings for HTTPS and LDAPS. This allows for controlled access to the IPVAs within the PBX hosting provider’s private network from external. Each customer PBX uses its associated Frontend for NAT, that is, each Frontend provides NAT for all customers that have it associated as Frontend. The number of customers per Frontend is limited by the number of NAT maps that can be created, which in turn depends on the length of the resulting config file line. Currently, there is a limit of approximately 290 maps per Frontend. 2 distinctive maps are needed per customer
* Additionally, some maps shared by all customers (e.g. for services like Metadir, FaxServer, Reporting) are required. About 20 maps should be reserved for this
* So we end up with the aforementioned number of 135 customers per Frontend
* It is recommended to use a kind of syntax that allows the admin to deduce from the external port number the service type and the associated private IP. For example use 4-digit external ports, the first digit represents the service type(e.g.8 for HTTPS to the PBX, 9 for LDAPS to the PBX), the following 3 digits the associated IP-address(e.g. 007 for internal IP 10.0.0.7). In our example the external port 9007 would be mapped to the internal IP 10.0.0.7 port 636.
* since the Frontend is also used as NAT-router for UDP-messages(i.e. SIP signalling from the customer PBX to the SIP provider), an ''UDP-NAT port-range''(IP4/General/Settings) must be configured. The size of the port-range should be at least as large as the number of customer PBXs served by the Frontend, each SIP Trunk requires one (external, public) port in the defined range. By default the UDP-NAT port-range is ''0'', so no UDP NAT is possible. You must use a port range that does not conflict with other used ports on the Frontend (e.g. UDP-RTP Port-Range by default 16384 / 32767).

==== PBX ====
* ''System Name'' is the PBX hosting provider’s domain name (e.g. <code>hoster.tld</code>)
* ''PBX Name'' is <code>sbc</code>''n''
* ''Prefix for Intl/Ntl/Subscriber'' depending on Customers national numbering plan (e.g. for Germany and Trunk Prefix 0: <code>000, 00, 0</code>)
* registers as ''Slave PBX'' with the central license server PBX (''License Only'')
* receives required licenses from the central license server thus

===== Customer related Configuration =====
* One ''Session Border'' object for each (potential) terminal registration to a customer PBX
* ''Long Name'' as well as ''Registration to internal PBX/Name'' set tot he ''CPE-ID'' (see below)
* ''Password'' set to the ''customer registration password''
* ''Registration from external/Name'' set to the CPE’s hardware-ID (NetBIOS name) ''PBX Password'' ticked

See also [[#Configuration of customer related objects in the customer’s PBX and Frontend]]

=====Alternate RAS port=====
End-customer phones register to the PBX using H.323. Some CPE Routers (such as Linksys) are known to mess around with H.323 packets (namely RAS) may inhibit registration. To avoid this problem, the phones and Frontend should be configured to use an alternate port for RAS signalling. At the phone the RAS - port must be changed using the command <code>config add H323 /ras-port xxxx</code> , the Frontend must be configured to listen for RAS packets also on an alternate port using the command <code> config add H323 /ras-port-alt xxxx</code>.
The alternate RAS port configuration should be distributed to the phones in the staging section of the initial update-server configuration.

In few cases, the NAT router will still detect RAS-messages sent via an alternate RAS port. The NAT router will therefore do its faulty H323-NAT-entries in the RAS messages. As a result, phones behind the NAT-router will not be able to register at the Frontend.
Assuming that you configured the usage of an alternate RAS port and double-checked that the entered password (at the phone and Frontend) is correct/matching, you can enable the logging of H323-Registrations(Maintenance/Diagnostics/Logging) and look for a ''REGISTER-REJ'' message having the additional information ''Reason=Authentication failed''

REGISTER-REJ(200.205.64.202:9198),H323=IP200A-10-10-b4,Reason=Authentication failed

Since the password is correct, the Reason=Authentication failed indicates that the NAT router is still doing H323-NAT. To solve this problem, H323-NAT must be turned off on the NAT-router located at the customer site.

==== Security ====
Keep in mind that the frontend is exposed to any attack from the wild, deep space in internet. As such, you should take utmost care of any security related settings (you may want to review the ''security'' lesson in your latest advanced training). In particular, as you will never want to allow registrations w/o password on a frontend, make sure to set ''No of Regs w/o Pwd.'' to <code>0</code> (zero) in any frontend PBX configuration.

=== Media-PBX ===

==== Services ====
* The media-PBX needs to have http access to the customer PBXs in order to play e.g. announcements or voice-mails. This is why the HTTP client credentials for URLs <code>http://</code> and <code>https://</code> via <code>paccess@hoster.tld</code> have to be set as explained above.
* The media-PBX must be configured to have ETH0 (default interface) connected to the ''public network'' and ETH1 connected to the ''hoster network''.
==== PBX ====
* One PBX-type object per customer. Both ''Name'' and ''Long Name'' set to the ''customer id'', “Number” set to <code>#</code>+''uniq number out of customer id''.
* One Gateway-type object <code>HTTP-EXT</code> with no number. This takes registrations from customer PBXs to for media data
* User-type object <code>MOH</code> with number <code>###10</code>. This is to register the MoH source
* User-type object <code>TONE</code> with number <code>###11</code>. This is to register the <code>TONE</code> interface. Make sure that you cut off the <code>###11</code> in the route to the TONE interface.
* User-type object <code>HTTP-OUT</code> with number <code>###12</code>. This is to register the media-PBX’s local <code>HTTP</code> interface to offload media data such as WQ announcements and voicemail

=== Customer PBX ===
Each customer has a unique ''customer-id'' which is used to derive various names and identifiers (see above). It is derived from (part of) the customer’s name and a sequential number. Something like e.g. <code>Kuenkel00001</code>.

The customer PBX is located within the private part of the PBX hosting provider’s network. Because of this, it cannot send media data to the CPE (which is the end customer’s private network). Media has to be sent via the associated Media-PBX thus, as this is ''dual-homed''.

:* the associated Frontend is used as ''Time Server''
:* ''Unknown Registrations'' is turned on with ''With PBX Pwd only''. This is to enable ZCD (Zero Configuration Deployment) for CPE
:* ''System Name'' set to the customers email domain (even if it is <code>googlemail.com</code> or <code>yahoo.de</code> as it does not need to be unique. Therefore it's necessary to set the customer PBX’ ''Master GK-ID'' property to the value of the media-PBX’ ''System Name'' property.
:* ''PBX Name'' set to the ''customer ID''

==== Handling of calls to MOH, TONE or HTTP-interface ====
As explained in the previous section, the customer PBX cannot send media data to the CPE but must use the respective resources on the associated Media-PBX. Calls to the Media-PBX are routed using GW-interfaces (i.e. Relay) on the customer PBX. Therefore the first step is to register a GW-interface (e.g. <code>GW1</code>) to the <code>HTTP-EXT</code> on the Media-PBX.
=====MOH=====
* Go to PBX/Config/General an enter as "External Music On Hold" the name of a non-exisiting object (e.g.<code>_customer_moh_</code>)
* Go to Gateway/GK an register a GW-interface (e.g. <code>GW2</code>) to this non-exisiting object (e.g.<code>_customer_moh_</code>). The registration will be accepted, in the PBX you will see a PBX-object called <code>_MOH_</code>
* Assuming that you followed the examples before, <code>GW1</code> would be the GW-interface registered at the Media-PBX. In the routing table (Gateway/Routes) configure a route from <code>GW2</code> to <code>GW1</code> and prepend the number used for the MOH-object on the Media-PBX(e.g. <code>###10</code>). The Route in our example would be <code>GW2 -> ###10 GW1</code>
* If you want to play a custom MOH, additionally enter the MOH-URL in the "Music On Hold URL" field(PBX/Config/General). The URL will be retrieved by the Media-PBX, as a result it must be retrievable by the Media-PBX (e.g. 127.0.0.1 in the URL will be the local-host address of the Media-PBX)

=====TONE=====
* to use the TONE interface of the Media-PBX, route calls to the GW-interface registered at the Media-PBX and prepend the number used for the TONE-object on the Media-PBX(e.g. <code>###11</code>).
* since the Media-PBX has only one TONE interface, it will generate the same TONE for all customer-PBX using it. If a customer-PBX needs a different TONE-interface, you have to create am additional Media-PBX.

=====HTTP=====
* the HTTP - interface is needed when an HTTP-URL is retrieved an played as an announcement. The "Extern Name/No" field at the respective PBX-objects (e.g. WaitingQueue) is used to offload the playing of the announcement to the Media-PBX.
* at the customer PBX create a Gateway-type object <code>HTTP-IN</code> with no number. This takes registrations from a a GW-interface (e.g. <code>GW3</code>) at the customer PBXs
* when configuring an announcement URL (e.g. at a WaitingQueue), enter as "Extern Name/No" <code>HTTP-IN</code>. The URL will be retrieved by the Media-PBX, as a result it must be retrievable by the Media-PBX (e.g. 127.0.0.1 in the URL will be the local-host address of the Media-PBX)
* In the routing table (Gateway/Routes) configure a route from <code>GW3</code> to <code>GW1</code> and prepend the number used for the MOH-object on the Media-PBX(e.g. <code>###12</code>). The Route in our example would be <code>GW3 -> ###12 GW1</code>

==== Global Objects in the Customer-PBX ====
===== <code>default</code> Template=====
* ''Config Template''-type object with ''Name'' <code>default</code>
* ''Hide from LDAP'' und ''Critical''
* ''Store Phone Config''
* all check-marks ticked in the ''License'' tab
* the ''Access'' column needs an entry for <code>@</code>''customer.tld'' (this is the ''System Name'' from the PBX configuration) with all check-marks ticked
* within the ''Config'' column, there is only a setting for LDAP Config (''Directories'') as follows:

<code xml>
<phone>
<loc cc='country-code' ac='area-code' ntp='0' itp='00' pbx='subscriber-number'/>
<ldap id='2'
tls='1' port='ldap-port-map-to-pbx-on-sbc, e.g. 9004'/>
<ldap id='3'
enable='1' tls='1' mode='basic'
addr='sbc-ip-address' port='ldap-port-map-to-metadir-on-sbc, e.g. 9007'
dn='PBX Name' pw='??' base='dc=PBX Name'
attr='sn,givenName,company' phone='telephoneNumber:D,mobile:M,:@'/>
</phone>
</code>

'''pw for ldap id 3 is critical: this allows everyone access to the customer directory data via LDAP. If this is not acceptable, the password needs to be removed from the template and configured manually by the end customer'''

==== Configuration of customer related objects in the customer’s PBX and Frontend ====
From an administrative point of view, no configuration specific to the individual device should be necessary for registration of a CPE. The default NetBIOS name (e.g. <code>IP232-01-02-03</code>) is used as registration name thus. This must be used as ''Registration from external'' in the corresponding SessionBorder object thus (for each potential CPE, there must be one SessionBorder object on the associated Frontend, see above).
The registration password used by the CPE and thus the ''Password'' in the SessionBorder object must be set to the ''customer registration password'' (which is specific to this customer, not to the CPE).
The ''Long Name'' as well as the ''Name'' for ''Registration to internal PBX'' in the SessionBorder object (hence the registration name for the CPE set in the customer PBX’s user-type object) is a combination of the ''customer ID'' and a sequential ''customer CPE ID'', e.g. . <code>Kuenkel00001-001</code>. The ''customer CPE ID'' starts with 0 for each customer. This allows for more meaningful data when viewing traces from e.g. the Frontend. Moreover, this scheme allows for nice filtering the object view on the PBX by customer name.
The password to register the SessionBorder objects from the Frontend to the customer PBX is always the globally used ''PBX password''. Hence the ''PBX Password'' check-mark must be ticked in the ''Registration to internal PBX'' area of the SessionBorder object on the Frontend and the ''PBX Pwd'' check-mark in the ''Devices'' area of the user object in the customer PBX. Initially though, no ''Devices'' shall be present in the user object, as this allows ZCD for the CPE.
[[Image:SBC_registration.png]]

=== Update Server ===

Tasks:
* Staging (e.g. installation of suitable trust list for HTTPS)
* Firmware update
* Backup of configuration data for CPE and customer PBX
Backup of CPE data is done to the virtual CF card of the customer PBX. Backup of customer PBX data is done to its Frontend.
There is no device or device-type specific update script.
Structure on the customer PBX
<pre>
/DRIVE/CF0/
update/
backup/
backup-mac-date.txt
</pre>

The backup folder on the customer PBX (<code>/DRIVE/CF0/update/backup/</code>) must be set writable but not readable under ''Services/HTTP/Public compact flash access'' so that CPEs can write their backup.

Firmware files are stored on a folder of the associated Frontend. Although this implies that they need to be duplicated to all Frontends, it simplifies the configuration and distributes load.

The generic update scripts are stored in (<code>/DRIVE/CF0/update</code>) on the Frontend. <code>staging.txt</code> is the CPE staging code, <code>update.txt</code> the regular update script. Both scripts make extensive use of [[Reference10:Concept_Update_Server#Setvar_command| update variables]].

Staging proceeds in 3 steps:
* CPE is configured to use the generic hosting staging interface (http://config.innovaphone.com/init) as ''Update-URL''
: This is a publicly available web service, (this service is currently experimental!) relates a requesting device to the hosting provider and customer pbx based on the serial number. If the device can be identified, the update server URL is rewritten to the PBX hosting provider’s appropriate Frontend (based on data that is defined in my.innovaphone). For more information, see [[Reference10:Concept Provisioning].
* CPE executes the Frontend-wide staging script (<code>staging.txt</code>). This performs some init-only tasks
* CPE executes the Frontend-wide update script (<code>update.txt</code>). This performs day-to-day tasks (such as backup)

File structure on Frontend
<pre>
/DRIVE/CF0/
update/
staging.txt - staging script
update.txt - regular update script
global.txt - overrides for global settings
local.txt - overrides for Frontend-local settings
set-customerid.txt - overrides für customer specific settings
staging/ - special staging scripts
global.txt - overrides for global settings
local.txt - overrides for Frontend-local settings
set-customerid.txt - overrides für customer specific settings
dev-IPxxx.txt - device type specific settings
cfg-phone.txt - device class specific settings
cfg-gateway.txt - ditto
firm/ - firmware
nnnnnn/
bootxxx.bin
ipxxx.bin
</pre>

In order to be accessible during firmware updates, the drive (<code>/DRIVE/CF0/update/firm/</code>) must have read (and only read) access on the Frontend under ''Services/HTTP/Public compact flash access''. In order to be accessible from the devices, drive <code>/DRIVE/CF0/update</code>) needs to be readable (and only readable). Both can be achieved with a single <code>/DRIVE/CF0/update/</code> entry.

Assigning the initial update URL (<code> http://145.253.157.5/redirect.php </code>) to CPE is for further study. It can be done as usual (DHCP), but this requires co-operation by the end-customer which may be a problem. Of course it can also be pre-configured by the hosting provider. In the latter case, the URL must be configured to the device after any long reset (factory settings).

===== Update Script Security =====
Update scripts may include registration password (although encrypted) to facilitate automatic registration with almost no user intervention (cf. set-''customerid''.txt above). By definition, staging scripts are readable by everyone (as they are used to configure otherwise unconfigured devices, so no kwowledge of credentials can be assumed). There is no easy way around this. One option would be to define a password for the web site hosting the scripts. This would then imply that the password needs to be configured to the CPE, which is undesirable from an administrative point-of-view. Moreover, with innovaphone gear (that is, when a web server internal to an innovaphone device is used), the only way to secure the scripts with a password would imply to use an admin account and password – clearly unacceptable from a security point-of-view.

To secure the update scripts, a mechanism based on innivaphone's device certificates must be employed. See [[Reference10:Concept Provisioning]] for more details.

==== Deployment ====
===== Initial =====
Create once-only services
* Kerberos and Kerberos Backup
* Create a new account for the PBX hosting provider in my.innovaphone (if the generic staging is to be used, see above)

===== Shared Services =====
Create services shared by a set of customers:
* Frontend
* Media-PBX
* Metadir
* Reporting LinuxAP
* Fax Linux-AP
* copy update/staging scripts (global.txt, cfg-*.txt, dev-*.txt) tot he Frontend drives (those are identical on all Frontends)
* create appropriate local.txt on Frontend

===== New Customer =====
* create IPVA with customer PBX
* create appropriate <code>set-</code>''customer-ID''<code>.txt</code> on Frontend
* create appropriate user objects on customer PBX as well as corresponding SessionBorder objects on Frontend
* create project for customer in my.innovaphone, set ''URL'' to the PBX hosting provider’s <code>staging.txt</code> on the appropriate Frontend (e.g. https://212.124.38.120/DRIVE/CF0/update/staging.txt) and the encoded public key of the hosting providers RootCA as ''Trust'' (as taken from a config file)

===== CPE =====
* Add device tot he customer project in my.innovaphone
* factory reset (optional, of course)
* set <code>http://145.253.157.4/redirect.php</code> as ''Command File URL'' in ''Services/Upate''
* wait for or force poll
* CPE registers with the Frontend and customer PBX as <code>_UNKNOWN_</code>

=== On-Site (Customer) Support / Debugging ===
==== Alarms and Events ====
* Alarms, events should be saved centrally on the Frontend, this way the admin has a full picture of all events and syslog in a Frontend-cluster. The CPE devices are configured by the staging script to send their events/alarms via HTTPS to the Frontend server.
** incoming Alarms/Events should be authenticated by the Frontend server, the CPEs must be configured (during staging) with the appropriate HTTP-client credentials. The account used for the HTTP-login must be configured with ''Viewer'' rights on the Kerberos - server.
** the received Alarms/Events can be further forwarded by the Frontend server to a Syslog-server. The received events can be then written in a database/text-file and used for further evaluation.
** the local event and alarm list is always kept in local Flash memory. The number of entries to keep can be configured in the Services/Logging tab. Since your Frontend-Server should not generate a large amount of events/alarms, you can use the default values(last 50 local events are stored in Flash memory).
==== Syslog ====
* the CPEs should not create logs, all relevant information(i.e. state of user-registrations) is retrieved from the Event/Alarm-list
* IPVAs(e.g. customer PBX) should generate logs and store them locally on their CF-card
** the recommended Syslog settings are ''PBX calls'' and ''Gateway calls''
** depending on the amount of generated logs (i.e. the size of your Customer PBX), the [[Reference9:Services/Logging | Max File Size]] should be set accordingly. You should capture at least 4 days of log information(e.g. allowing to inspect log information created before a weekend)
* if its required that CPE devices generate logs, it will be necessary to store the log-information on a central server(e.g. Frontend server). However incoming Logs cannot be authenticated by the Frontend server, since this function is not implemented in the innovaphone LOG-server. If incoming Logs should be authenticated, a Linux-AP should be used as central Log-server (the Linux-AP offers the possibility to authenticate incoming logs)
==== Config backup ====
* Phone configuration is backed up to the customer PBX CF, using the Update Server mechanism.
* the configuration of devices in the Hoster-network( e.g. Media-PBX, etc.) are saved on the CF-card of the Frontend-server

====Accessing the web-interfaces of devices====
* All devices (including CPE) have joined the Kerberos domain. As a result, all administrators are able to log in (provided they have access to the customers network, TeamViewer is an option)

=== Reporting (Multiple PBX) ===

NEEDS TO BE UPDATED (TLE)

The LinuxAP VM for reporting needs to have quite a large CF to be able to store all CDR data for a reasonable time period.

* VMWare disk size should be 50GB initially. This is based on a rough estimate of 200 customers and a time frame of 1 year
: rough estimate. Time will tell
* RAM 1GB

==== Naming Conventions ====

To grant access for customers (and reseller) to the Reporting login page (https://Reporting-IP-Adress/apps/innovaphone-reporting/user/login.php), it's nessesary to create a cdr filter called "base filter" and a user login which is bound to this base filter.
These logins and filters can only be edited and created by the hoster (i.e. cloudkom).
Since the customer can't change his credentials we use the "customer ID" and the "customer registration password" for further steps.

As we mentioned in chapter [[#Customer_PBX|Customer PBX]] each customer needs a uniqe PBX name, but different customers may share the same "System Name".
For this reason it's nessasary to set the Grouping-ID in the Reporting application to ''PBX Name'' (as set in ''Config/PBX'').
Never change this setup because filters are depending on the Grouping ID!

'''Filter parameters for customers:'''

* Base Filter: <leave it empty>
* Filter Name: ''customer ID'' (which is the ''PBX Name'', i.e <code>Kuenkel00001</code>)
* PBX Name: ''customer ID'' (which is the ''PBX Name'', i.e <code>Kuenkel00001</code>)

'''User configuration for customers:'''

* Name: <customer ID>
* Password: ''customer registration password''
* Base Filter(s): ''customer filter name''

For reasons of billing (or whatever) it could be fine for resellers to have a filter for all of -his- sold PBXs

'''Possible filter parameters for reseller:'''
(in fact, the reseller id is a customer id, because the only difference is the filter content)

* Base Filter: <leave it empty>
* Filter Name: ''reseller ID'' (i.e. innovaphone00001)
* PBX Name: ''customer ID'' +
* PBX Name: ''customer ID'' +
* PBX Name: ''customer ID'' ...

'''User configuration for reseller:'''
* Name: ''reseller ID''
* Password: ''reseller registration password''
* Base Filter(s): ''reseller filter name''

====Konfiguration Reporting ====
* Grouping ID: PBX-Name
* Create filter and user logins for the customer
* LDAP?
* Report Mails?

====Konfiguration Kunden-PBX ====
===== Gateway / CDR0 =====
* ''Type'' <code>Remote-AP-S</code>
* ''Address'' ''Reporting Linux-AP IP address''
* ''Port'' <code>443</code>
===== PBX / myPBX / Call List Service =====
* ''Type'' <code>Remote-AP</code>
* ''Host'' ''Frontend-IP-addr:HTTPS-Portmap-on-Frontend-to-Reporting-App''
* ''User'' <code>innovaphone-reporting</code> ?????
* ''pass'' <code>reporting</code>

In contrast to the CDR0 interface, the Call-List-Service doesn't offer the possibility to choose the ''Type'' <code>Remote-AP-S</code>. The myPBX client decides which protocol to use (HTTP or HTTPS) depending on the URL (http or https)used to connect to the PBX. So if myPBX uses HTTPS to connect to the PBX, it will use also HTTPS to connect to the Reporting-App.

=== Fax Server ===

NEEDS TO BE UPDATED (afI)

A LinuxAP VMware disk size of 50GB should be sufficient. Configure the size of the virtual drive before starting the Linux installation for the first time.

Since the FAX-Interface must be reachable from the public network, it must be offloaded from the Customer VM to the Media Gateway. The SOAP connection from the Faxserver application will be still directed to the Customer VM/PBX.

[[Image:Routing_fax.png ]]

On the customer VM we have to configure a Gateway Object and routes to and from GWxx which is registered on the Media Relay instance. We reuse HTTP-EXT registration at this point to send Fax calls to Media.
====Customer PBX Settings for Faxserver====
** Gateway Object Name= <code>Fax</code>, Number= <code>some prefix number used for Fax extensions</code>, Option "Prefix" activated
** add the Gateway Object to the SOAP/TAPI group, in order it is visible for SOAP applications connecting to this PBX
** Prepare User Objects for Fax usage:
*** Fax License must be assigned
*** E-Mail must be configured and must match the sender address

====Customer Gateway Settings for Faxserver====
** Fax GWxx, Register as Gateway, 127.0.0.1, Name= <code>Fax</code>
** Route GWxx (Fax) --> ###13 GWyy (HTTP-EXT)
** Route GWyy (HTTP-EXT) --> GWxx (Fax)

For multiple customer PBXes we define a single Gateway with FAX Interface:

====Media PBX====
** Gateway Object Name= <code>fax</code>, Number= <code>###13</code>

====Media Gateway====
** Interface FAX, Internal Registration, 127.0.0.1, Name= <code>fax</code>, Coder G711,20 , "Enable T.38"
** HTTP-Client must be configured to use [[Howto:Hosting#Kerberos_User|credentials for programmatic access]] to be able to read and write to WebDAV Server on LinuxAP with Faxserver application.

====Faxserver Instance====

For each Customer VM an own Faxserver instance on the LinuxAP must be configured (one LinuxAP, multiple Faxserver instances for every Customer).

** SOAP connection must be configured to point at the PBX running on the Customer VM
** E-Mail Account configuration is important to be able to deliver E-Mails to the Faxserver via SMTP
*** The E-Mail account, configured at the Faxserver instance, will be used at teh Customers Mailserver to authenticate against the Mailserver on Faxserver

==== Mail to Fax Gateway ====
Für Kunden, auf deren POP3 Server aus Cloudkom Netz nicht zugegriffen werden kann, wird ein SMTP Server auf Basis von IP-AP aufgestellt. Dort können die Kunden dann per E-Mail die Faxe anliefern. (<mantis-issue id=89710/>)

Use Case "Fax verschicken":
*Kunde schickt aus dem E-Mail Programm ein Mail mit PDF-Anhang an z.B. <code>+497031730099@fax.cloudkom.com</code>
*Rufnummer für Zielfax muss im User Part der To: Mailadresse stehen (im Beispiel ist es +497031730099)
*Das passende Postfach für Fax Server des jeweiligen Kunden wird anhand der From: Mailadresse bestimmt.

Damit die From: Adresse nicht gefaked werden kann, werden nur authentifizierte SMTP-Verbindungen zugelassen. Der Kunde muss dazu bei sich im Exchange einen "SMTP Send Connector" für die Domäne fax.cloudkom.com einrichten ([http://msexchangefaq.de/connector/sendconnector.htm]) mit Basic Auth over TLS.

Als SMTP-Server kann man ein Postfix mit Postgresql Erweiterung nehmen, damit man die Kunden Daten (Domains, Postfächer, Logins) direkt aus der Fax Server Datenbank lesen kann.

Als POP3-Server (damit Fax Server die Mails lesen kann) wird dann Dovecot eingesetzt.

Beschreibung der Implementierung: [http://wiki-intern.innovaphone.com/index.php?title=E-Mail_Fax_Server_Gateway_(Project_Cloudkom) E-Mail_Fax_Server_Gateway_(Project_Cloudkom)].

=== Directories ===
There are 2 services provided to customers:
# the PBX directory
# an optional company-wide directory (external LDAP)
==== PBX Directory (extensions) ====
* one NAT port map is to be created per customer on the Frontend for port LDAPS (TCP source port xxx to target Port 636)
:This port can be used in the phone’s ''Port'' field in the ''PBX'' area in ''Phone/User/Directories/PBX''. The PBX LDAP server’s IP address is implied from the registration data. This way, the CPE will in fact access the customer PBX’s LDAP server as opposed to the Frontend’s one
* LDAPS can be used safely, as the CPE’s LDAP client does not verify the certificate anyway (although it would be trusted as it is derived from the PBX hosting provider’s RootCA)

====External Directory ====
=====Estos Metadir=====
*there is one Metadir server per Frontend which serves all customers associated with this Frontend. Hence there is one inbound NAT port map that maps one port to the Metadir server’s LDAPS port. This map is used from all customers. Customer specific directories are implemented as logical views in the Metadir LDAP server, not as separate servers
*there is thus one distinct LDAP node (dc=''customer-ID'') per customer
* there is also one distinct replicator for each customer (which is used to import the customers directory data in to the Metadir)
**Replicator
*** The customer would provide its contact database as „comma separated CSV (Windows)“ file (e.g. as exported from Outlook)
*** The file must have the columns ''"Surname","Firstname","Company","Busines Phone ","Mobile Phone"''
*** All numbers must be in E164 format, e.g. +49703173009123
*** File name is <code>contacts.csv</code>
*** The file is uploaded to the Frontend’s CF-file system
*** Each customer has its own directory (<code>https://212.124.38.120/DRIVE/CF0/directory/</code>''customer-ID'') on the Frontend. This is the place <code>contacts.csv</code> has to be uploaded to. For this to work, the path must be set to write-only on the Frontend!
*** Customers can use e.g. [http://curl.haxx.se/dlwiz/?type=bin&os=Win32&flav=-&ver=2000%2FXP curl]. Syntax: <code>curl --verbose -k https://212.124.38.120/DRIVE/CF0/directory/customer-ID/ -T contacts.csv</code>. Note that standard WebDAV clients will probably not work due to the fact that this directory is write-only.

Structure on Frontend
<pre>
/DRIVE/CF0/
directory/ - write-only w/o authentication
customer-ID/
contacts.csv
</pre>
* Metadir has a duplicate of the Frontend’s directory structure
<pre>
C:\directory\
script.bat - script that retrieves customer directory data <code>contacts.csv</code> from the Frontend, called by replicator
contacts.csv - sample
customer-ID\
contacts.csv - customer data
</pre>
* Metadir’s per-customer replicator imports the local contacts.csv when run. Before doing so, it calls script.bat which retrieves the appropriate contacts.csv from the SB (this behaviour needs to be configured in Metadir, ''Database Wizard'', '' Zusätzliche Anwendungen(additional applications)'').
: script.bat copies the then-current customer’s contact.csv from the Frontend using curl (curl - syntax: <code>curl --verbose -k -u user:password https://10.30.255.0/DRIVE/CF0/directory/%1/contacts.csv -o c:\directory\%1\contacts.csv</code>
: user:password in script.bat are administrator credentials valid on the Frontend (as contact.csv files are read-only, see above)
* Each replicator will be run every 3 hours
: The replicator can also be triggered from the cmd-line (calling e.g. <code>TextReplicator.exe </code> as found in the Metadir installation directory. Start a replicator from the GUI and have a look at lastreplicator.bat in the install directory). This may be useful if the PBX hosting provider has implemented a user portal to upload the contact data.
* The replicator is created using the ''Replicator-Wizard'' and associates the .csv columns to the respective LDAP attributes/DB field names. A combination of all attributes is used as primary key
: [[Media:Cloudkom-Metadir-Replikator.png | Replicator Overview]]
*LDAP-nodes:
** LDAP node access authentication is based on distinct, per-customer users, username (=''customer ID''), password(=''customer registration password''). No IP address restriction is used.
** profile is ''Default'' always, no customer specific profile is required (this is handled using the phone’s ''Dialing Location'')
** [[Media:metadir-LDAP-Knoten-config.png | Settings]] can be seen in the screenshot
Here is how to export contact data from Outlook 2010:
** as far as we know it is only possible to export your own contact list. In case that all users use a global contact list, this list has to be copied first into your own contact entry list.(select [Global List](e.g. IP Kontakte) -> right click -> copy -> choose own contacts)
** From Outlook ''File -> Open -> Import -> Export to file -> comma separated values (Windows) -> (select contact folder) -> "Map custom fields"(german: Benutzerdefinierte Felder zuordnen) -> choose "Surname","Firstname","Company","Busines Phone","Mobile Phone"-> Finish''
*LDAPS
** Just any certificate will do on the Metadir, as the LDAP client does not validate the certificate
** Metadir uses port 714 for LDAPS, Frontend needs an appropriate NAT Map
=====LDAP-Client=====
* directory settings should be set in a PBX ''Config template''-type object in the customer PBX and applied to all user objects there
: [[Media: Cloudkom-Metadir-Ldapclient.png | Phone/User/Directories/External LDAP Server Settings]]
: ''Dialing Location'' settings need to be done according to the customers trunk line settings
=====myPBX=====
* external directory lookups for myPBX are done by the PBX rather than by the myPBX client itself. The directory configuration is taken from the users phone configuration (as stored in the PBX). This of course presents a problem as the phone configuration will use the external Frontend NAT map data for the Metadir, whereas the PBX itself – sitting in the PBX hosting providers private network – needs to use Metadirs private address. There is a special configuration parameter for the PBX which sets the LDAP configuration used for any directory lookup performed for myPBX:
: <code>config add PBX0 /ldap-default-addr local-ip-addr-of-metadir /ldap-default-port 714</code> (714 is Metadirs LDAPS port)

=== Voicemail ===
Voicemail is run on the customers PBX as usual. However, as discussed before, the Webmedia (a.k.a <code>HTTP</code>) interface on the media PBX must be used. VM xml script and recorded voice mail files are stored on the customer PBX’s CF card as usual though. The trick is to have a registration to the customer PBX’s voice mail object. If this is present, voice mail will use this registrations to terminate media data rather than the local Webmedia (which is the default).

The registration on the local VM object needs to connect calls to the remote HTTP interface on the media PBX. This is implemented using a GWx interface in the customer PBX’s gateway level which registers to the VM object. There is a route from this GWx to the GWy which in turn registers with the media PBXs <code>HTTP-EXT</code> object (there are no calls to the VM object ever).

==== PBX ====
* voicemail-object
** Hardware-ID = <code>vmrelay</code>
** Script-URL (installed on local CF Card as usual) = <code>https://customer-PBX-IP-address (not 127.0.0.1!)/DRIVE/CF0/vm-de/vm.xml?$_divconn=false</code> (this URL will be evaluated on the media PBX, this is why 127.0.0.1 will not work!)
** suitable extension depending on customers numbering plan

==== Gateway ====
** vmrelay GWxx, Register as Gateway, 127.0.0.1, Name= <code>vmrelay</code>
** Route GWxx (vmrelay) --> ###12 GWyy (HTTP-EXT)

==== MWI ====
Simpkly works as is.

==== Mail MWI ====
Mails are sent through the PBX hosting provider’s own mail server. This may require authenticated SMTP. This needs to be configured in each <code>email.xml</code> in the customer PBX’s voice mail installation:

* message sender
* Subject of MWI mail
* mail server
* credentials

Apart from the mail subject (which is language dependant), this is identical for all customers, so it can be done once and copied then.

User Email addresses must currently be set in each user object’s ''URL'' attribute (or in a separate file in the user directory).

=== Operator ===

to be updated

innovaphone Operator v10 can be installed in local client location and connects directly to client IPVA using HTTP-SOAP connection using the same Port used for HTTP management defined on the SBC.

All SOAP communication goes through this HTTP connection so all features will be available and working properly. The LDAP configuration of the Operator v10 is similar to the one performed in the IP Phones.

=== Mobility ===

Mobility needs access to DTMF tones and thus to the RTP media stream. As the customer-PBX has no public IP address, again, the media for all mobility calls must be routed through the media-PBX linked to the customer PBX.

In the media-PBX, we need a ''media-relay-loop'' gateway-type object (no ''Prefix'' check-mark ticked) with a gateway GWx interface registered to it. On the media's gateway level, there is a route that routes calls to this interface directly back to that interface. This GWx interface used must have the ''Media-Relay'' check-mark ticked. Calls to the media-PBX's ''media-relay-loop'' object are thus echoed straight back to the PBX. However, the media-stream will be terminated on the media, so that it is available from the media's public IP address.

On the customer-PBX, a gateway-type object is created that sends calls to the media's ''media-relay-loop''.

For incoming mobility calls to work, they must be recognized within the gateway level (that is, the mobility object's extension must be known) and routed through the aforementioned media-loop before it ends up in the client-PBX's mobility object.

For outgoing calls, the fork destination must be set such that the outgoing mobility calls are first sent through the media's ''media-relay-loop'' before they end up in the client PBX's trunk.

=== DECT ===

to be updated

=== Backup ===
''Disaster recovery'' backup ist o be done by the operator of the VMware infrastructure.

User data (PBX config, CPE configuration) is backed up by the update server as outlined above.

=== UI/Portal ===
Innovaphone does not supply a dedicated UI for hosting scenarios (neither for the PBX hosting provider nor for the end customer). It is envisaged that hosting providers will craft their own tool for this, as this is highly related to the provider’s business model.

===Special scenarios===
* Customer-setups where the phones are in separated private networks, e.g. home-office without VPN to LAN of main-office. In this case the phones in different private networks can not send RTP-packets to each other. To overcome this problem, the media-relay option at the SessionBorder object must be enabled for those SessionBorder objects that have registration from "foreign" networks. If the Frontend is used as RTP-endpoint(i.e. by activating the media-relay option), the UDP-RTP port-range(by default 16384 / 32767) must be configured.

===Limitations===
* Customers-setups with Master-Slave PBXs are not supported. The problem here is that the Master & Slave PBX are within the hosting provider’s private network and some PBX mechanism (e.g Registration-Redirection, Soap) would return IP-addresses with IP-addresses from the provider’s private network to device at the customer site. (e.g. a phone registering at a PBX might get an indication to register at another PBX - however the IP-address in this Redirection is in the hosting provider’s private network, therefore unknown to the phone).

= Related Articles =
[[Howto:A rough estimate of IPVA Performance]]

File:SBC registration.png

2014-01-25T13:30:18Z

Ole: Registration of phone via SBC on Front End to Customer IPVA

Registration of phone via SBC on Front End to Customer IPVA

Reference10:Concept Voice Recording 2014

2013-09-13T08:55:59Z

Ole: pcap2wav is in v7 tools, not in v6

'''This article is preliminary – The product and functions described are not actually available and can be modified or canceled in any moment!'''

The innovaphone Voice Recorder application allows recording while the innovaphone Player application a comfortable search and playback of phone calls.

All kinds of calls can be recorded:

*Incoming calls

*Outgoing calls

*Calls from innovaphone IP Phones

*Calls form 3rd party IP-Phones

*Calls from IP-DECT phone sets

*Calls from analogue phone sets

*Calls from with mobile phones (mobility, forking)

*Calls done on a legacy PBX (soft migrations scenarios)

The solution requires an innovaphone PBX, the recording toll and two applications;

*a recording tool described in this document called “Recorder”

*a search and playback tool called “Player”.

The usage of the Player is not part of this description, a separate localized help and user manual is available.

While the recorder (this description) has to be installed by professionals and the maintenance is done by system administrations people (and therefore English wording and this description is good enough) the player is operated by End user and may be not digital native, skilled or knowledge base workers.

Note also that the setup of the player is a typical admin job and not described in the player manual.

== Scenarios ==

Recording is possible on each logical Gateway and therefore on external lines (ISDN, SIP or H323 Trunks). In theory “external” is just a convention, even internal calls passing through those gateways could be recorded, but this is more a theoretical issue. An innovaphone gateway can also be used as a “recording” bar and introduced between a legacy PBX and the PSTN. Remember anyway that the innovaphone PBX must be activated and the Reporting tool is required.

Being recording defined on a logical Gateway opens different options, for example activate recoding just for a dedicated route. For example just for incoming calls or just for some outgoing calls. Typical examples for such a setup are business and private calls, where just business calls should be recorded. For example if a call is done using “0” as prefix recording is done, using “9” not.

Or normally (“0”) no voice recording is done, but if a user access to a trunk with a particular prefix (“9”), recording is on. This for example is widely used in selling contracts by phone (like mobile phone carrier do); they call the customer and if the customer agrees in the commercial proposal to extend or to “sign” the contract they will call back the customer again using another prefix and record now the conversation.

Recording rules can also be executed automatically because configured in the gateway setup. For example you can exclude certain user from recording or vice versa, doing recording just for some users. For example all calls to the financial operators are recorded, all other calls not. Or all users are recorder but the management not.

All that is a question of setup in then innovaphone gateway (and PBX) and not described in detail in this document, being standard features and described in many other articles (and being part of the advanced technical training).

Please note that recording starts when a connection is established and terminates when the connection is terminated. That means that eventual waiting situations in waiting queues, music on hold sequences calls etc. are recorded too.

Keep in mind that each extension that should be recorded must be active in the reporting, means require a recording license. Even if you operate a soft migration you must go up in the PBX to a dummy user with reporting on and back again down to the relay.

Notes: Recording can be done just in G711A on a logical gateway as endpoint. If you need to record internal calls they must always transit a logical gateway (with the media relay flag on).

The recorded files are in a wave format and can be played with a normal Mediaplayer, the delivered Player allows additional features.

The recorded records are stored in an indicated path and a copy of the records can be done automatically.

Errors and events are stored in a log file and alarms tracked; a mail can be send if an alarm occurs.

It is possible to limit the duration of the storing period; older files will be deleted automatically. This is to avoid disk full errors, keep in mind that this kind of systems usually works unattended all the time.

The number of player and recorder is unlimited.

Recording can be done also directly from the IP-Phone. Doing VR using the IP-Phone has the following advantages or disadvantages; it depends on your point of view and the scenario.

- CPU-Load: No CPU power from the PBX is required, a Phone has enough CPU-Power to do that and more, and therefore it becomes an extremely scalable solution. If you do not use an external WebDAV server but a CF anyway the PBX CPU has some load (playing WebDAV server for the Phone)

- All calls on the phone are recorded (not just those crossing a gateway), so even internal calls (basically everything the phone is doing).

- Al users working on the phone are recorded. This means also that each possible user on the phone must have the reporting license otherwise a call from that user will cause a major alarm.

- Transferred calls to other extensions are after the call transfer no longer recorded. In case of gateway recording it is different, until the call cross the gateway recording is done.

- If you mix both setup in a scenario you should avoid that a Phone is doing recording and cross a gateway doing recording too. If that happen recording is done in two points and you double for nothing disk space and resources (and confuse everybody).

- Only innovaphone IP-Phones IP2x2 series and “A”-types (like IP110A, but not IP110) can performing VR directly.

Switch on the recording has to be done in the phone setup file, there is no menu option. Mode information about that is in the online help of the recorder setup.

== Standard Recording ==

Operating in the “Standard Recording” (STD) mode recorded calls are converted and saved after the call has finished.

A recorder has to operate in one mode (STD or TCR), a mixed scenario is possible using two recorders, setup in this case has to be done very carefully.

== SRTP ==

Recording of encrypt conversation is possible, no particular setup is necessary, the system will decrypt automatically the media stream and store the conversation in unecnryptet wave files for further processing.

== Thread Call Recording ==

Operating in the “Thread Call Recording” (TCR) mode only marked calls are converted and saved, all other calls are deleted automatically.

A call can be marked manually from the user or automatically from his innovaphone IP-Phone. A call can be marked during the call or after call, but within a defined time period (for example until 5 minutes after the call-end). Not marked calls are deleted while marked calls will contain the entire call, so from the beginning on (even if marking is done during or after the call).

Marking calls during the conversation can be done only using innovaphone IP-Phones while all type of phones can mark a call after the conversation. To mark a call after a conversation the user must call a XML object.

In a typical setup the user will hear a confirmation if he is marking a call, something like “the last conversation was recorded and will be saved” or similar.

If marking is done using an innovaphone IP-Phone during the call (pressing the redial key) audio or no audio can be played. For example an automatic advice like “this conversation will be recorded” or similar can be played.

=== Setup TCR ===

This paragraph discusses the different setups and aspects for Thread Call Recording. If you are not interested in those details skip it.

TCR require a XML (TCRec.xml included in the software package of the Last call recording feature, see Related Articles, see Related Articles, go to the article and follow the download [http://download.innovaphone.com/ice/wiki-src#lcr http://download.innovaphone.com/ice/wiki-src#lcr] ), you have to create a directory and copy the xml in, create a VM-Object in the PBX and insert those parameters in the recorder setup (TCR panel). The XML can be called directly or using the recording functions on the innovaphone phones. If called directly the xml will play the audio file Track1.g711a, if called through the recording function of the IP-Phone the file Track2.g711a. If the files are not present the user will hear nothing. A solution for the confirmation could also be to play just a “beep” if calling directly the xml. You could copy the beep.g711a file (for example from the VM) and rename it. A better option is record them using the universal track recording tool, see related articles at the end iof this page.

Some additional information if you use the recoding function of the innovaphone IP-Phone:
Keep in mind that this function will not really recording the voice but just calling the XML (the recoding is done by the Gateway or the phone, but directly and not using this function). As explained the XML will play the file Track2.g711a if present, but to hear the announcement you have to use on your phone at least version 10.0887 or higher and switch on the flag “Two Way Media” in the Recording section of the phone setup. The rest is the usual one, if you setup “Mode=transparent” each call will flagged as “to record”, if Mode=manual you have to press the redial key to flag. No problem if the user presses more than one time the record key, just the actual call will be recorded.

The xml itself will terminate after playing the Tack 1 or 2, delayed for 2 seconds. If the user press the redial key in this way he will see in the display of his IP-Phone appear “Recording” for 2 seconds and has a feedback (even if no tone is played) that the conversation is flagged to record.

== Last Call Recording/Repeat ==

See relative article.

Do not confuse this feature with the Instant Play (rescue mode) feature of the innovaphone Player.

== Overview ==

The recording itself is done by the innovaphone gateway. In each logical gateway a recording path can be configured as a URL; that means that the voice will be recorded in a file, this file can be on a compact flash or on an external WebDAV server. The recorder application copy the recorded file, read out the reporting, combine both, and rename the file. The original file on the compact flash/WebDAV is deleted. The new filename is formed using date and time, caller and called user, direction of the call, the time to answer (ringing time) and the unique ID number. The recorder converts the file from pcap to the wave format and stores the converted file in a directory. If requested a copy of this record can be saved in a second directory (for example a SAN or NAS disk area). A maximum number of storage time expressed in month can be defined, older files will be deleted automatically. In this way no disk space overflow will be in unattended systems. Parallel to the payload (the wave voice file) also a XML file containing the reporting data is created, the name of the file is the same than the one of the voce and just the extension is xml instead of wav. That is basically what the recorder is doing; copy and convert recorded files, retrieve data from the reporting, renaming of the files and copy them to different destinations as well as keeping track of history.

The player allows searching and browsing of records, show the oldest or newest first, can filter the search etc. For example it can be displayed calls in any direction or just incoming or outgoing calls, or calls from a certain number or to a certain number, using even wildcards for quick filter options. See relative description for details. Once the calls a displayed they can be marked using windows usual methods (one, many, all, range, etc.). The marked files can be copy, past, deleted or played in a playlist. A record in the playlist can be marked and the player allows the usual operations of a windows media player. Looping and audio signal before playing the next record in the playlist is included as well as moving inside the playlist from one call to the other. If all that sounds complicated calm down, it is quite simple in using and designed for “users”.

The player can even operate in a mode called “rescue mode” or “direct play mode”. If switched in this mode the latest record is always on top. This is a typical requirement for an emergency center operator, he is interested in replay the last or lasted recordings in a quick and simple mode.

The player shows also the reporting details and generally the most important data of the conversation. If recorded files are copied also the relative reporting information is copied.
Many player can be installed and work in the same moment in a scenario, while the recorder typically is just one. So the recorder is a kind of server and the player a kind of client. More recorders can be installed in a scenario and if necessary a player can be installed on the same PC where a recorder is working. Being the recorder always on usually it will be installed on a dedicated machine doing just that located in the server room.

But remember that the recording job is done as described by the gateway. So even if a recorder application is switched off voice recording is done. The idea anyway is not that the recorder is switched off and just sometimes switched on to retrieve the files. But if you must shut down the application or reboot or enter in setup, no data will lose.

The following diagram shows the logical interfaces between the innovaphone voice recorder, the innovaphone player and the rest of the equipment.

[[Image:Player07.png]]

The connection between the player and the recorder is a TCP link, it is not mandatory and uses just to show the recorder status and performing a recorder reset in case of failure. The player main data source is the disk where the records are stores. There could be active many player at the same time, and in theory also more than one recorder. One player could monitor just one recorder, but it is possible to start more player on the same PC.

== Requirements ==

=== Recorder ===

The recorder application requires a PC or server with Windows OS Win 7 or higher, also windows server 2008 (Windows 2003 server not tested) or higher is supported.

Disk space: One minute of conversation requires about 1 MB of memory. A lot, but a TB HD today is cheap and for example even a 500 GB Raid 1 external NAS is not real expensive. Typically a recorder should have a Raid system, but remember that the recorder is able to do also a security copy. The copy to an external security drive is possible because in many scenario’s customer has to archive records for many years.
The recorder requires a NTFS file system (no FAT32), usually today a standard on PC.

No particular memory or CPU speed is requested, standard editions are quite good enough. Invest better in a good quality because in professional environments those machines have to work for many years.

Voice recording requires a Version 10 innovaphone PBX and a Version 10 Reporting tool. No compatibility with older versions is possible. PBX and/or Reporting can run on a gateway as well as on VMware.

The recording of the pcap file is done by the PBX firmware and requires a Compact flash or a WebDAV server. The recorder software will detect those records and copy them on the real storage path. Therefore the storage requirement for the CF/WebDAV not real high (but remember always 1 Minute =1 MB, so if you must record 30 conversations for 30 minutes = 900MB).

Voice recorder and Player could run on the same PC as well one single PC can also be used for the reporting, recording, playing and webdav server (and PBX if you like). So anything on one server is theoretically possible.

The two extreme setups are:

*innovaphone PBX on the GW, reporting on the GW, pcap recording on the CF, recording application on a PC

*innovaphone PBX on the PC, reporting on the PC, pcap recording on the PC, recording application on a PC

Each combination between is possible.

=== Player ===

The player application requires a PC with Windows OS Win 7 or higher, the Mediaplayer is necessary. All that on a standard office PC is installed and you have to do nothing in particularly.
Require Framework 3.5.
In theory also a Windows server 2008 could host the player, but in the server versions the media player typically is not installed and there are also different DLL missing. So if you have time or you are well Microsoft server trained face also that if necessary (normally not).

=== Legal Aspects ===

Please take extremely care about the legal issue: in most country voice recording of telephone calls is forbidden and persecuted by law as a crime. In some country it is legal in certain circumstances, for example you have to inform the caller that the call will be recorded. That can be done automatically (using for example a waiting queue) or “manually”, telling the far person that this call will be recorded. Of cause also this announcement should be recorded. In some country recording is legal without any announcement for certain services, for example in case of emergency calls or calls to the police. In most country authority like the secret service do not really care about all that stuff and do what they want, but this is probably not your case.

So inform yourself and the customer about the local legal situation. Using the recording tools is on your own risk and innovaphone will not take any responsibility, even not for eventual malfunctions. See also our general trading terms, valid even for this solution. If you have any doubt about legal questions in using voice recording; don´t do it, don’ use it!

== Installation Sep by Step==

In this and many other wiki articles everything you need to install and operate the product is (hopefully) described. Partners some time have the problem that they could not find a logical flow in the description and the do not realize what is important and what interesting, but not essential.

To help here a simple step by step instruction, all details and comments are in the other paragraph and, of cause, in other articles.

1. Check the Software version of your PBX, it must be 10 or higher otherwise do an upgrade or forget this recording. You PBX must be up and running and to test you need at least 2 Phones.

2. Check that you have a valid license for the recording, if not just a demo-mode is possible, after 20 minutes the recorder stop and you have to restart him again.

3. Your CF should be working fine, create a directory to buffer the pcap files (for example http://123.123.123.123/DRIVE/CF0/IF_REC).

4. Setup the recording gateway, see http://wiki.innovaphone.com/index.php?title=Reference10:Voice_Recorder/Setup#Gateway_Setup . If you want to do a test with internal phones you have to assure that in ca ll from one user to the other this gateway will be involved. Create for example a access code to this GW and flag Media-Relay. If you call this access code followed by the internal number ths should happen. Of cause if you have a real trunk the you will do all that using the relative GW. At the end of the story your call must passing the recording gateway, check it; open you PBX interface, click on gateway and calls: you should see that the call goes through the recording GW. A pcap file will created at the CF directory indicated in the setup of the gateway (the same one you create in pass 3).

5. Start up the reporting (on a xx10 GW or IPVA), it must be up and working, you should be able to see the reports of the call done using the recording gateway.

6. Create SOAP user, a blank empty user object called SOAP (or _TAPI_ or _whatever_)

7. Create a root directory where the recorded files should be stores (for example “c:\mytest\” or “G:\myExternalDrive\”).

8. Now create a directory and put the innovaphone_recorder.exe and the pcap2wav.exe in the same directory (this is done automatically if installation is done with the installer).

9. Start the application and open the setup.

== Installation ==

While the Recorder is simple in using but complex in setup and works “hidden” for the user, the Player is simple to setup but has a huge user interface. The Player is typically installed on one or more PC of users. Therefore for the Player a user description (the “Player manual”) is available. The Player description is available also in localized version; please check the relative section in the innovaphone Wiki.
Recorder and player applications are single executable file. The setup is stored in a xml file located in the same directory where the application is running; no registry entry is done; if you delete the directory where the recorder/player is in, the application is de-installed. If you like install on the same computer the recorder and the player application you have to create two different directories and copy the applications twice. Automatic execution is possible inserting in the auto start directory the recorder application.

Please note that the setup file is in xml format, but his content is encrypted.

The installation tool will copy all reqired files, if you install manually copping file note the following issues:

If you install a recorder application manually you must copy the “pcap2wav.exe” utility in the same directory!

Note: This utility “pcap2wav.exe” can be downloaded in the V7 application folder, access to a directory and download the “tools” Zip file; inside you will find the pcap2wav.exe.
The recorder is not a service because there is a full user interface available. To ensure that the recorder starts up even after a boot put the application in your autostart folder. In the setup an option to start up minimized is available.

Before starting the recorder application check the following items on the recorder PC:

*the directory where the recordings should be stored must be visible and it must be possible to create subdirectories, try using the file explorer

*If backup is requested also a write access to the backup path must be possible (but it is not necessary to be able create subfolders).

*Access to the reporting tool must be possible, use a browser to check

*The access to the CF (or the WebDAV server) must be possible, try to map a drive and access to the directory where the pcap files are

Do the setup the innovaphone PBX, the gateway and the reporting.

See eventually also http://wiki.innovaphone.com/index.php?title=Reference10:Voice_Recorder/Setup#Recorder_Setup for a better understanding of the requirements.

If you do now a call which has to be recorded this call must be logged in the reporting tool and a pcap file must be created in the indicated url path. Go only ahead if that is up and running.

Now start the recording software and open the setup and set the values. An online help will explain the single parameters. Maybe it is also a good idea reading first the rest of this article.

The installation of the Player is similar just simpler. After installing start the application, enter the setup and that its. But it has no sense install or setup a Player without before having a working recorder.

On a single PC multiple Recorder and Player can be installed, simple install and run them on different directories.

=== CPU load ===

The power of the innovaphone CPU on the different gateway models is high enough to ensure the recording of all ISDN cannels (or the same number of SIP/H323 Trunk) on that gateway. If recording is done on a CF the innovaphone PBX CPU will be involved also in the copy operation (if recording is done on an external WebDAV server no CPU load of the PBX for copy is required). After the copy operation no more CPU power of the PBX CPU is required.

The reporting CPU (which is anyway the second core in case of a gateway or a separate CPU in case of VMware) has some small workload because the recorder checks each 5 seconds the reporting.
Using the player will cause no workload for PBX, reporting or recorder CPU, so just the local workstation CPU power is require. Therefore the number of player is practically insignificant for any CPU load.

=== Logging ===

Recorder and the Player applications write an individual error log, this log is a text file and stored in the same directory where the application is. See online help for file names and description of the other files used by this applications.

The recorder can also write a trace file; if tracing option is switched on all operations of the recorder are logged in a file named “iREC_sys_log.txt”. Please not that this files become very large if the option is always on, and this file will not be deleted or resized automatically. The idea is not to keep on tracing all the time but to switch on the trace during the first period or in case of trouble checking.
If enabled in the setup the player stores all special operations in a central log file. All copy, delete and move operations done using the player are in this way stored automatically in a central log file.

A “user operational” log file is in a central point and unique for all players installed. Here all user manipulations done using the player applications are reported, so copy or delete is traced. This file is named “iREC_Player_log.txt” and located in the “\TMP” subdirectory of the root recording directory. In this way all operations of all Player-User are visible at a glance in one single file.

=== Security ===

The setup of the recorder and player is stored in an AES encrypted setup xml file. Therefore the user cannot manipulate or read out setup values. The access to the setup can be protected with a password. If a user deletes the setup file the software assumes that this is a new installation and allows access to the setup without password. If the user enters the correct path for the recording the software read out a centralized password and it is not possible to save the setup without that password. There is no way to read out or decode the password and this means that if you, as administrator, forget the password you have to clear the centralized password and the setup of the recorder and re-configure all. Try to avoid that situation and remember your password.

The centralized password is in the located in the “\TMP” subdirectory of the root recording directory and named “SPlayer.xml”. It is also encrypted of cause.

The Reporting xml data string can be modified with any editor and therefore it is possible to encrypt the connection data.

In the setup of the recorder you can switch on the option “Encryption reporting data”. If encryption is on instead of an XML a XMC file extension shows that the XML data stored are AES encrypted. The player detects automatically if the reporting data are clear or encrypt and will show them independently. In the first column header of the player a looked/unlooked symbol is displayed showing the encrypt/clear file mode. If (using the player) a encrypt records is copied it will be automatically decrypt, while moving a file (cut and paste) will not change the original file mode. In this way a clear copy of a xml can be done from an authentic encrypted data string.

== Voice Recorder operation ==

The recorder can operate in 3 layouts; minimized in the taskbar, viewing a small window or an extended panel.

[[Image:Recorder01.png]]

Switching between small and large view is done pressing the “>” key, press “_” for minimize.

[[Image:VR010.png]]

=== Start up ===

During start up the basic operational parameter are checked while the master alarm is disabled. The master alarm supervision is just switched on after about 20 seconds. This is necessary because sometimes network operation during start up fails, but becomes up in a second attempt. For example mapping of network drives fails frequently at the first attempt but once up they will remain connected without any problem. The sequence of testing is done by design and the software will not proceed in operation if a parameter fails but continuously try to fix it.

This initial health check during start-up is done in the following order:

*checking setup: try to understand if the setup parameters are reasonable and in particularly if the WebDAV drive or CF can be mapped. If mapping fails the “SETUP” lamp will be red, error message “Setup not o.k.” is viewed.

*checking reporting: pings the reporting, if ping is o.k. try to load a dummy page. If ping or dummy fails the “REPORTING” lamp is red, error message “Reporting Link failure” is viewed.

*checking to access to the recording directory (url): try to read out the indicated path, if fails “PCAP” lamp is red, error message “PCAP directory access fails” is viewed.

*checking if access to the storage path is possible: If reading fails the “DISK” lamp is red, error message “Store path fails” is viewed.

If in the setup no backup path is indicated this last task is skipped and the Backup lamp is grey. Otherwise the access to the path is tested, if access fails the “BACKUP” lamp is red, error message “Backup path fails” is viewed.

If a test is passed the relative lamp becomes green. If after start up 6 lamps are green (or 5 green and one grey) everything is working fine and the message “Normal Operation” is displayed in the System status line.

After 20 second the Master alert supervision is switched to active, an eventual error causes a Master Alarm (see relative section).

=== Normal operation ===

The check counter shows you how many times the recorder reads out the recording directory and checks the reporting. As you see al 5 seconds a reading attempt is done, if data are found further processing operation will start. This counter goes automatically to 0 reaching 9999 and shows you that the software is working and checking but has no further signification.

The counter “Channels in recording” shows you how many recordings are ongoing. The panel shows you the ID of each recording file and the initial recording time. In this way you can see how long a call is jet in recording.

If the call ends it will disappear from the list. If there are more records then default lines a scroll down will automatically appear.

If you click the innovaphone logo the software version is displayed. The version is also displayed in the headline of the setup.

===Extended view ===

If you enlarge the window with the “>” key two additional panels appears.

[[Image:Recorder02.png]]

The left one shows the regular normal operations, the right one the errors and basic messages (like Start-up). The messages displayed of the error panel are stored automatically in an error log file while the messages of the status panel only file if that is enabled in setup. Both windows can be cleared pressing the relative button. This clearage is just an “optical” issue; no file is deleted or similar. Both windows shows up to 100 entries, if entry becomes too large a scrollbar appear automatically. If “full” the oldest message will be cleared. On top the error panel can also display the last 30 Error reading out the error file.

Pressing the “<” key the windows will be resized again.

There is no operational difference between the different layouts. The recording application starts always with the small window stile.

=== Setup ===

Open a separate window, see relative online help.

http://wiki.innovaphone.com/index.php?title=Reference10:Voice_Recorder/Setup#Recorder_Setup

Note: during setup the recording timers are disabled, this means that no normal operation is done. For normal operation the setup must be terminated (with or without saving).

=== Alarms ===

[[Image:VR011.png]]

About 20 seconds after startup, and always during normal operation, alarms are detected from a particular master alarm routine. Some alarms are self-healing, others not. If an alarm occurs the relative source is switched from green to red, if an alarm disappears from red to green. You can simply test is, just shut down the reporting during operation and you will see that the reporting indicator becomes red. If you start up the reporting again the indication will switch automatically from red to green.

An alarm master routine will control the system and summarize the alarms. On the left side there is an indicator “Master alarm” and two buttons, “RESET” and “OFF”. While the alarms can toggle and appear and disappear, the master alarm once triggered will indicate that there was at least one serious error. The detail can be shown in the error log, but the point is that the master alarm shows you the correct operation in time and store the error event.

With the “OFF” button the master alert can be switched manually off. If the master alarm is switched off the “OFF” button will blink red to indicate this exceptional situation. A manual switch off of the master alarm could be necessary during setup or test, or simply to avoid receive alarm emails being anyway in front of the application or similar.

If the master alarm detect at least one error it will be switch on the Master Alarm status, the relative indicator will blink red, a warning triangle will appear and, if configured in the setup, and a warning email is send to the administrator.

[[Image:VR012.png]]

The icon of the application in the taskbar is changed and a warning triangle appears on the recorder logo; also operating in minimized status the Master Alert situation is visible.

[[Image:VR013.png]]

As explained the master alarm will not recover if an error disappears: to reset the master alarm the “RESET” button has to be clicked. Clicking the Reset Key the Master Alarm becomes again armed and will trigger again if an error is detected.

The single errors are partly described in the startup section while the “SOFTWARE” indicator will go into alarm if there is an unexpected error in the software. While some errors are expected and supported and will not cause such an error (for example “no files” if you browse an empty directory) others are not (for example if the decoding of pcap file fails). So while some errors could be an exception (like the failing of file conversation) others could be persisting (like “disk full”) or are simply bugs.

A particular expected, but not tolerable error is described in the next section.

=== Reporting time out error ===

Each extension recorded must have the reporting license active. If that is not (or of the reporting is switched off for a longer period causing loss of CDR data) the recorder got a pcap file with an ID number, but no CDR data for that file from the reporting. The recorder waits up to 120 minutes to receive valid CDR data, after that time he will give up and save and convert the file with incomplete data. If that happened the “REPORTING” lamp will switch to red and a master alert will trigger. Instead of caller, called number etc. a “U” (like “unknown”) is used in the filename. So if a file name contains “ .. _U.U.U_U_ ..” means that there was a reporting time out. The only usable data are the ID and the creation time of the file, that is the reasonable starting time of the recorded conversation.

The things goes even worst if there is a call up for more than 2 hours, because this situation is similar for the recording application: a record in recording is detected but there is no valid response from the Reporting for that record ID . After 2 hours the recorder try to solve the situation, switch on the reporting error lamp copy and rename the recorded file, but then will happen also a Software error, because the deleting of the pcap file will fail (because the file is jet in use). Remember: while “_U_” should not happen, “_U_” because of busy conversation should never happen. Therefore we recommend limiting the speech time to 120 minutes (the recorder trigger if the value is more than 121 minutes). That can be done in the main window of the innovaphone PBX, field “Max Call duration (h)”, put 2 in. To less 2 hours for conversations? Send us an email we will enlarge that timeout to your requirement.

=== Terminating ===

If you try to stop the application a warning message appears, if you confirm the recorder application stops.

== Files ==

Voice files are stored a subdirectory of the indicated path in the recorder setup.

The files are Wave stereo files where the left channel contains one speaker and the right channel the other one.

There are two working sub directories: the directory “/TMP” contains the central activity log file where the player applications will report their activities (“iRec_Player_Log.txt”). The second is the directory “/REC”, it is a working folder. Both folders are created automatically. The recorder creates a subdirectory for each month, so for June 2013 for example a directory “2013_06” is created and all recorded files in that period will be stored there. Note that in the backup folder no subdirectory folder are created and therefore all files in the backup path are in the same folder.

The recording files are always a couple, one file contains the audio (in wave format, can be reproduced using also standard audio player) and an xml file with the same name containing connection data. Both files are anyway independent and our player handles automatically a single wave file as well as the pair with additional detailed connection data.

One goal of the recorder was to produce a wave file that contains all relevant data.

The format of the name of the Wave file is the following:

"Date and Time of conversation start" + "internal user" + "direction" + "external user" + "time to answer in seconds" + "serial number"

Example:

“2013_06_24_1638_39_o_0800102_7_75c1f48e909d31188fc00903306225f.wav”

Date: 24.06.2013

Time: 16:38

Internal: 39

Direction: o = outgoing

External: 0800107

Time to answer: 7 seconds

Serial: 75c1f48e909d31188fc00903306225f

The file “2013_06_24_1638_39_o_0800102_7_75c1f48e909d31188fc00903306225f.xml” contains the reporting data of this call.

The player retrieves the name of the wave file and displays the data from the xml file if present, otherwise at least the data inside the filename.

If you like you can open the xml file even with an editor and see all the relevant data, much more then displayed using the player.

The player shows also the duration of the call (the recoding) and other details. See relative description.

== Related Articles ==

[[Reference10:Player_Voice_Recording]]

[[Reference10:Voice_Recorder/Setup]]

[[Howto:Last_Call_Recording]]

[[Howto:Universal_Track_Recording_Tool]]

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

Howto:Pcap

2013-05-16T11:44:34Z

Ole: /* Capturing with wireshark */

With remote PCAP, network traffic can be captured directly from another network device, instead of capturing the network traffic from the own device.

==Remote PCAP==
===Requirements===

* You should have installed the latest wireshark release >= 1.6 with the latest innovaphone dll [http://www.wireshark.org/download.html Wireshark Download]
* Required and optional tools (innovaphone_winXX.dll and log2pcap.exe): open the [http://download.innovaphone.com/ice/download/p/6.00/apps/ V6 application folder] and download the tools.zip. You will just need the innovaphone_win32.dll or innovaphone_win64.dll, depending on your installed wireshark version, 32 bit or 64 bit. Older wireshark versions won't work with the latest innovaphone_winXX.dll!
* To view the standard debug output, you have to install the innovaphone_winXX.dll, which you'll find in the tools package. Just copy the dll to your wireshark plugin directory and pay attention on your currently used version (e.g.: c:\programme\wireshark\plugins\1.6.0\).
* To view ISDN LAPD/Q.931 packets, you also have to install the innovaphone.dll.
* Open the [http://wiki.innovaphone.com/index.php?title=Image:Pcap_example_isdn.zip example pcap file with lapd and q.931 packets] to check your current installation. It should look like this, if you have the innovaphone_winXX.dll correctly installed:

[[Image:Pcap_sample_isdn.jpg|center|thumb|200px|PCAP ISDN example]]

===Setting up the rpcap server===

* The rpcap server can be any innovaphone device.
* The remote pcap server is disabled per default. To enable it, just go to Diagnostics->Tracing and check the "Enable" flag in the "Remote PCAP" group. If you are experiencing problems, also enable the trace flag with "config add PCAP /trace".
* To capture all ip traffic (udp and tcp), enable the "IP (all tcp/udp traffic)" flag in the group "IP". Otherwise just enable all the trace flags on the modules you want to capture.

===Capturing with wireshark===

Open your wireshark and the capture options dialogue. Choose "remote" from the dropdown list and
Type "<IP-ADDRESS>/TRACE" into the host field.

It should look like this: (Screenshot from older Wireshark, v.1.2.2 and from newer Wireshark v.1.8.6)
[[Image:Wireshark_1.2.2_trace_settings.PNG|left|thumb|200px|Wireshark capture options]]
[[Image:Wireshark_1.8.6_settings.png|center|thumb|200px|Wireshark capture options]]

Then just click on "Start" to start capturing.

===Supported protocols===

* ISDN: LAPD L2/L3 with dissector innovaphone.dll (enable Diagnostics->Tracing TELX/PRIX/PPP)
* AC DSP: dsp with dissector Ac49xPacketRecording.dll (enable Diagnostics->Tracing->VOIP DSP)
* PPPoE: flag "/pcap" on module(s) PPPOE0/PPPOE1 enables pcap tracing

* All TCP/UDP protocols which are supported by native wireshark dissectors or other dissectors which can be found searching the internet.
e.g.:
SIP
H.323
H.245

Enable the corresponding flags under Diagnostics->Tracing, if you only want to see specific UDP/TCP protocols. To see all, enable the "All TCP/UDP Traffic" flag under Diagnostics->Tracing.

==PCAP Log==

Another possibility to get a pcap log file is to open http://IP/log.pcap
This file has a limited size just as the normal log file.

==log2pcap==

You need the tool log2pcap from the tools package, if you have a log.txt file, which contains pcap packets and you want to view them in wireshark. You can find the tool in the apps tool package (see above).

Usage:
# log2pcap.exe input1 input2 ... inputX
# drag&drop one or more files on the log2pcap.exe
# use an asterix like "log2pcap c:\*.txt" to convert all txt files into pcap files. Things like c:\test*.txt are not supported.

* The resulting file name is always inputx.pcap (e.g. log.txt is converted into log.txt.pcap).

Note: if you have a trace of a little endian box (e.g. IP3000, IP21) with V6 SR1 or SR2, you have to use the "-srlefix" switch (available since 08-1007):

log2pcap.exe input1 -srlefix

==General Informations==

===Reading PCAP Traces===

Non-IP Pcap packets will nevertheless show source and destination IP addresses. 127.0.0.1 stand in for the traced device. So if for example a Q.931 SETUP messages is sent from 127.0.0.0 to 127.0.0.1, then it is an incoming setup.

===Disabling PCAP traces===

You can disable the whole pcap tracing. Just configure a /disable-pcap to the CMD0 module. This can be useful if you do not want to see pcap traces in your log file.

===Used ports===

* The debug traces are encapsulated in UDP packets with port 4.
* The isdn traces are encapsulated in UDP packets with port 4.
* The ac dsp traces are encapsulated in UDP packets with port 50001.
* Wireshark uses port 2002 to connect to the running rpcap-server
* rpcap packets are transfered over a dynamically assigned port between server and client

===Additional Remote PCAP trace===

You can trace the remote pcap protocol with adding the trace flag by "config add PCAP /trace" if you are experiencing connection issues.

===Timestamps===

Since V7 Hotfix 26 and V8 Hotfix 13, the ntp timestamp is used instead of the uptime in rpcap packages. In converted log files with log2pcap, uptime is still used.

==Known Problems==

* Converting a log from a little endian box (like IP3000 and IP21) with firmware V6 SR1 or SR2 with the tool log2pcap will only work with log2pcap 08-1007 or higher and the switch "-srlefix", see [[:#log2pcap|log2pcap]].
* Ac49xPacketRecording.dll works only with 0.99.7. Higher versions of wireshark won't start, if this dll was copied to the dll folder!
* Also some other dlls, contained in the tools package, won't work with each wireshark version. Just innovaphone.dll is always working.
* Even though ''All TCP/UDP Traffic'' is turned on, packets sent to the box acting as rpcap provider to a port that is not handled by the box (that is, where no listening socket is active) will currently not be shown
* If you use a 64-bit Windows Pc then you will need another innovaphone.dll, which is also contained in the latest tool package.
* The custom IP header from captured innovaphone packets contains dummy values for TOS (0), id (0), fragment offset (0) and TTL (128)

==Related Articles==

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

File:Wireshark 1.8.6 settings.png

2013-05-16T11:42:07Z

Ole: Wireshark v.1.8.6 capture options

Wireshark v.1.8.6 capture options

Howto:Listen to several conference rooms

2012-11-21T13:57:18Z

Ole:

{{Template:3rd Party Input}}
How to listen (one way media) to several conference rooms at once, with one phone or loadspeaker, without disturbing the conferences.

==Applies To==
This information applies to

* IP PBX V9 with [[Reference9:Gateway/Interfaces#Conferencing_interface_.28CONF.29 | CONF]] resources available.



==More Information==
[[Image:Conf_listen.PNG]]

We have several ongoing conferences. We want to monitor / listen to all of them without leaking audio from one conference to an other.
Each listening service need 4 additional conference resources, so it is important to have a gateway with enough resources (IP810 or more powerful).

The solution is to send the audio from each conference through an additional muted conference room before the audio is sent to the final conference room that mix the one-way audio from all the other conferences.

Because of one conference room can't send audio direct to an other conference room, we have to send it out to the GW part and into the PBX again.

==Configuration concept==
[[Image:Conf_listen_config.PNG]]

* '''Conf-x''' are the ordinary conference rooms. They are BC conf objects. They have to be active in the '''Conf-x''' group.
* '''Conf-x listen user''' are standard user objects, always participate in the corresponding conference room. They have also to be in the '''Conf-x''' group.
* '''GW1''' is a gateway with registration. Let it register on the corresponding '''Conf-x listen users'''
* '''Route ^*21#''' routes the calls into the PBX again, ex via trunk object, and mute the next conference room with the *21# command.
* '''Conf-x muted''' are the conference rooms. They are BC conf objects. They have to be active in the '''Conf-x mute''' group.
* '''Conf-x muted user''' are standard user objects, always participate in the corresponding muted conference room. They have also to be in the '''Conf-x mute''' group.
* '''GW2''' is a gateway with registration. Let it register on the corresponding '''Conf-x muted users'''
* '''Route''' routes the calls into the PBX again, ex via trunk object.
* '''Conf speaker WQ''' is a waiting queue object. It accept calls from '''Conf-x muted users'''. And it forwards the call with Call Forward No Reply after 3 seconds to '''Conf speaker''' conference room. The reason for the three seconds delay, is to wait until '''Conf-x muted''' is muted with the DTMF code *21#. If not, this DTMF had also muted '''Conf speaker''' conference room.
* '''Conf speaker''' is a conference room mixing together the audio from all conferences and send it to the speaker. It has to be active in the '''Conf-speaker''' group.
* '''Conf speaker user''' is a standard user objects, always participate in the '''Conf speaker''' conference room. The listening phone is registered on this object. You can also use 2N SIP netspeaker. It register on this object.

==PBX objects==
Create the BC conf objects, user objects and WQ objects.
Here is a screenshot from an example.

[[Image:Conf_PBX-objects.PNG]]

[[Image:Conf_BC-object-2.PNG]]

==Gateway and Routes==
Create the gateways and routes.
Here is screenshots from our example.

[[Image:Conf_GW.PNG]]

[[Image:Conf_Routes.PNG]]

== Related Articles ==

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

Howto:Listen to several conference rooms

2012-11-21T13:54:49Z

Ole: New page: {{Template:3rd Party Input}} How to listen (one way media) to several conference rooms at once, with one phone or loadspeaker, without disturbing the conferences. ==Applies To== This info...

{{Template:3rd Party Input}}
How to listen (one way media) to several conference rooms at once, with one phone or loadspeaker, without disturbing the conferences.

==Applies To==
This information applies to

* IP PBX V9 with [[Reference9:Gateway/Interfaces#Conferencing_interface_.28CONF.29 | CONF]] resources available.



==More Information==
[[Image:Conf_listen.PNG]]

We have several ongoing conferences. We want to monitor / listen to all of them without leaking audio from one conference to an other.
Each listening service need 4 additional conference resources, so it is important to have a gateway with enough resources (IP810 or more powerful).

The solution is to send the audio from each conference through an additional muted conference room before the audio is sent to the final conference room that mix the one-way audio from all the other conferences.

Because of one conference room can't send audio direct to an other conference room, we have to send it out to the GW part and into the PBX again.

Here is the configuration concept:
[[Image:Conf_listen_config.PNG]]

* '''Conf-x''' are the ordinary conference rooms. They are BC conf objects. They have to be active in the '''Conf-x''' group.
* '''Conf-x listen user''' are standard user objects, always participate in the corresponding conference room. They have also to be in the '''Conf-x''' group.
* '''GW1''' is a gateway with registration. Let it register on the corresponding '''Conf-x listen users'''
* '''Route ^*21#''' routes the calls into the PBX again, ex via trunk object, and mute the next conference room with the *21# command.
* '''Conf-x muted''' are the conference rooms. They are BC conf objects. They have to be active in the '''Conf-x mute''' group.
* '''Conf-x muted user''' are standard user objects, always participate in the corresponding muted conference room. They have also to be in the '''Conf-x mute''' group.
* '''GW2''' is a gateway with registration. Let it register on the corresponding '''Conf-x muted users'''
* '''Route''' routes the calls into the PBX again, ex via trunk object.
* '''Conf speaker WQ''' is a waiting queue object. It accept calls from '''Conf-x muted users'''. And it forwards the call with Call Forward No Reply after 3 seconds to '''Conf speaker''' conference room. The reason for the three seconds delay, is to wait until '''Conf-x muted''' is muted with the DTMF code *21#. If not, this DTMF had also muted '''Conf speaker''' conference room.
* '''Conf speaker''' is a conference room mixing together the audio from all conferences and send it to the speaker. It has to be active in the '''Conf-speaker''' group.
* '''Conf speaker user''' is a standard user objects, always participate in the '''Conf speaker''' conference room. The listening phone is registered on this object. You can also use 2N SIP netspeaker. It register on this object.

==PBX objects==
Create the BC conf objects, user objects and WQ objects.
Here is a screenshot from an example.

[[Image:Conf_PBX-objects.PNG]]

[[Image:Conf_BC-object-2.PNG]]

==Gateway and Routes==
Create the gateways and routes.
Here is screenshots from our example.

[[Image:Conf_GW.PNG]]

[[Image:Conf_Routes.PNG]]

== Related Articles ==

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

File:Conf Routes.PNG

2012-11-21T13:48:42Z

Ole:

File:Conf GW.PNG

2012-11-21T13:46:33Z

Ole:

File:Conf BC-object-2.PNG

2012-11-21T13:45:32Z

Ole:

File:Conf PBX-objects.PNG

2012-11-21T13:43:50Z

Ole:

File:Conf listen config.PNG

2012-11-21T12:18:32Z

Ole:

File:Conf listen.PNG

2012-11-21T12:08:17Z

Ole: 2N SIP speaker used to listen to several conferences

2N SIP speaker used to listen to several conferences

Reference9:Concept Linux Application Platform

2012-11-01T10:29:19Z

Ole: /* Linux Application Platform (IPxx10 Gateways) */

==Introduction==

The innovaphone Linux Application Platform permits to install innovaphone or custom applications for certain purposes, like Reporting or a Fax Server. 
It also allows to backup/restore configuration files, uninstall applications or see and backup logs. 
 
The Linux distribution Debian 6 (Squeeze) is used and linux kernel is 2.6.35.4. 
 
The architecture of the platform is armel. 
 

==Requirements==

There are two ways to use the innovaphone Linux Application Platform:

===On an IPxx10 Gateway===
* An IP0010, IP3010 or IP6010 Gateway
* Firmware Version 9
* A compact flash card with UDMA support (minimum 4 GB)
** We recommend SanDisk Extreme with UDMA and 90 MB/s or above

===As a Virtual Machine===
* VMWare Player/VMWare Workstation

==Installation==

Download the latest Linux Application Platform from [https://download.innovaphone.com download.innovaphone.com ]. 
You can download and install two different packages:

===Default Credentials===
* Web/Webdav: '''admin'''/'''linux'''
* Root-Login (e.g. with Putty): '''root'''/'''iplinux'''

===Disk space usage after first time installation===

====IPxx10 Gateways====

* /dev/sda1: 32 MB (fat32 partition with kernel, which is started by the IPxx10)
* /dev/sda2: 450 MB (ext2 initial installation partition)
* /dev/sda3: 120 MB (swap partition)
* /dev/sda4: 600 MB / xx GB depending of the size of the used CF card (ext4 partition, which is actually booted)

All in all about 1.2 GB are already in use after the initial installation.

====VMWare====

* /dev/sda1: 665 MB (ext2 initial installation partition)
* /dev/sda2: 120 MB (swap partition)
* /dev/sda3: 680 MB / xx GB depending of your pre installation configuration (ext3 partition, which is actually booted)

All in all about 1.5 GB are already in use after the initial installation.

===Linux Application Platform (IPxx10 Gateways)===

It is recommended to use CF-Cards with sizes of 8GB or more and the card '''must''' support UDMA! 
* Enable Linux under Linux General.
[[image:IPxx10_Linux_-_enable.png]]
* Enable Proxy-ARP on ETH0 or ETH1 [[ Reference:Configuration/ETH/IP|here ]]
* Decompress the downloaded package. You should have an image file like <code>linux_ipxx10_armel.img</code> now.
* Upload the decompressed file over the gateways web interface under [[ Reference9:General/Compact-Flash/Image ]]. Unmount the CF card if necessary. Select "Part 1" before starting the upload!
[[image:IPxx10_Linux_-_upload_image.png‎]]
* Reset the box (which also activates the config change of step 1).
* Configure IP under [[ Reference9:Linux/IP ]]: select either "Disabled" to assign a static IP or ETH0/ETH1 to receive an IP-Address from DHCP-Server behind ETH0 or ETH1.
* Configure the kernel file, which you find under [[ Reference9:General/Compact-Flash/General#Browse_CF_Content ]] on [[ Reference9:Linux/General ]] '''Linux kernel file''' (Currently <code>Image-6010-3.4.10</code>)
* Configure <code>root=/dev/sda2</code> under [[ Reference9:Linux/General ]] '''Kernel command line'''.
* If you want, configure the autostart flag.
* Submit your changes.
* Click the [[ Reference9:Linux/General ]] '''Start'''-Link. The page refreshes until Linux gets an IP and then tries to get a link to the Linux Web Server, which can take some time for the first time installation (~ 5 minutes to 2 hours).
[[Image:device_conf.jpg]]
* Open the Linux Web Server to see the installation progress (which might take several minutes too). The default credentials are '''admin'''/'''ipxx10''' (ex. ip810) for the IPxx10 gateway platform and '''admin'''/'''linux''' for VMware platforms.
[[Image:installation.jpg]]
* Enter the innovaphone device admin credentials when the installation has finished. Now wait until the page refrehses. The web server credentials are now the innovaphone device admin credentials.
* Linux install has finished.
* You will see now <code>root=/dev/sda4</code> under [[ Reference9:Linux/General ]] since Linux is running in on the fourth partition. You shouldn't change that unless you want to install Linux again.

===Linux Application Platform (VMWare)===

* Decompress the downloaded archive. You should have two files: '''IP-Debian.vmx''' and '''IP-Debian.vmdk'''.
* Now you have two possibilities (example for VMWare Player, VMWare Workstation should be similar):
** If you want to assign more than 4 GB virtual flash (8 GB since Hotfix 7):
*** Do '''not''' directly start/doubleclick the vmx file!
*** Start the VMware Player and Open the vmx file with '''Open a Virtual Machine'''.
*** Open '''Edit virtual machine settings'''.
*** Select the hard disk and '''Expand''' it under '''Utilities''' to the wished size.
*** Apply the change and klick '''Play virtual machine'''.
** If 4 GB (8 GB since Hotfix 7) are enough, simply double click the vmx file and Linux will start.
* The first time, a script will automatically configure a new partition, the web server etc., which will take some time. The waiting time depends on the CPU of the computer running the vmware player. In some cases the waiting time can be up to 30 minutes, in most cases the installation finishes in about 2-5 minutes.
* In the meantime, fetch your IP from the VMWare Player screen or login as root and get your IP address with the command '''ifconfig'''.
* Login to the web server to see the installation progress (it may take some minutes until the web server is up).
* Linux will restart automatically after the first time installation has finished.
* Linux install has finished.

===Hotfix Installation===
If you have already installed the latest version of the Linux Application Platform, simply download the Linux...HotfixIncremental for your platform (VM or IPxx10) or if you have missed some hotfixes, download the Linux...HotfixCumulative archive, which contains all hotfixes since hotfix1.
 
 
Upload this hotfix archive [[Reference9:Concept_Linux_Application_Platform#Upload.2FUpdate|here]].

====Refreshing issue on installation====
You might get a PHP error when the browser is refreshing during the installation. Just refresh (F5) the page and you'll get the installation progress again.

===Static IP?===
The Linux itself '''must''' be running in DHCP client mode to run properly. If you want to assign a static IP address, do it like this:

* On an IPxx10: assign a static IP under [[ Reference9:Linux/IP ]]
* On a VMWare: assign a static IP in your local DHCP server for your MAC address defined in the *.vmx file

==Administration==

===General===

====Change the root credentials====

Here you can change the credentials of the Linux root user. 
Default password: '''iplinux'''

====Configure Authenticated URLs====

Configure credentials for authenticated URLs. These credentials will be used in automatic backups. 
You can add/remove Urls with the '''+''' and '''-''' at the right side of the list.

* URL: the URL, e.g. https://172.16.123.123/backup
* User: the user for this URL
* Password: the password for this URL

====Configure NTP server====

Configures a NTP server.

* NTP Server: the IP of the NTP Server

====Change Timezone====

Default is Europe/Berlin but you can change that to a valid timezone (an error is given if timezone not present). 

====Change postgresql admin password====

If innovaphone Reporting is installed, you can configure another password for the postgres admin user. 
Default password: '''postgres'''.

===Web Server===

We use lighttpd version 1.4.28. The linux web server user is '''www-data''' and group user also '''www-data'''. Root directory for the web-server is '''/var/www/innovaphone'''. This information is mainly relevant if you plan to develope custom applications and integrate them into linux application platform.

Default users and password for the different levels on the Linux application plattform (see figure below):
[[image:Linux_Application_hierarki.PNG]]

====Change web server properties and public access to the web/webdav====
* Force HTTPS: enables redirection for HTTP to HTTPS
* Public Web Paths: these paths are not password protected, e.g. '/ap'
* Public Webdav Paths: these webdav paths are not password protected, e.g. '/backup'
** These paths are by default readonly. You can set the 'Write' flag to make the path also writable. This flag will be anyway ignored if credentials are provided. 

Enter a single '/' for a public root directory. All sub directories and files will be also public then. 
If you enter e.g. '/update/', the directory 'update' and all sub directories/files will be public. 
If you enter e.g. '/update', only the directory 'update' and its files will be public.

====Change the Linux web server credentials====

Here you can change the credentials for Web Server access.

If running VMWare, default password is '''linux'''. If running IPXX10, password is the one entered at the end of first installation (admin password of the device where linux is running)

====Change the Linux webdav access credentials====

Here you can change the credentials for webdav access.

If running VMWare, default password is '''linux'''. If running IPXX10, password is the one entered at the end of first installation (admin password of the device where linux is running)

====Change application access credentials====

If you have installed an application, which has the lighttpd-auth property set in its configuration file, you can configure a separate user/password for the applications web site. 
If you want to disable the separate authentication, leave the '''user''' field empty and enter the currently configured password. The authentication will be the same as the root web server authentication afterwards. 
One can just login on the application web site with this access.

A configured access overrides a configured public web path to '/apps/application-name'!

===Certificates===

The current server certificate installed on the web server is shown here. A self signed certificate, innovaphone-linux, is installed by default. It is recommended to change it with your own certificate.

It is also possible to trust or reject other certificates.

===Backup===

The web server can be configured to poll a Command File URL (on a web server). 
The backup process is similar to [[Reference9:Services/Update]]. 

An alarm server can be also configured to receive alarms during an automatic backup: [[ #Alarm_Server | Alarm Server under Diagnostics ]].

At the bottom you will see a list of the current automatic backup serials from the Command File URL and the log of the last automatic backups.

[[Image:backup_restore.jpg]]

====Command File====

Example:
saveinnovaphonecfgs http://172.16.123.123/webdav/backup/cfgs-#i-#b10.tar.gz

The available default commands are:

=====saveinnovaphonecfgs=====

Saves all neccessary configuration files (no application specific files) as a tar gz archive (so you should use .tar.gz as ending).

=====saveinnovaphonelogs=====

Saves all available (also application related) log files as a tar gz archive (so you should use .tar.gz as ending).

=====times=====
Executes the following command(s) only, if the specified time matches and only once per hour (independent of poll timeout value). 
Example:

<pre>
# both commands always executed
saveinnovaphonelogs http://xxx.xxx.xxx.xxx.xxx/webdav/backup/linux-logs-#i-#m-#b10.tar.gz 
saveinnovaphonecfgs http://xxx.xxx.xxx.xxx.xxx/webdav/backup/linux-cfg-#i-#m-#b10.tar.gz 
# commands only from monday till saturday at 10am and 11am executed.
times day:1,2,3,4,5 hour:10,11
saveinnovaphone-reportingcfgs http://xxx.xxx.xxx.xxx.xxx/webdav/backup/linux-innovaphone-reporting-cfgs-#i-#d-#b10.tar.gz 
saveinnovaphone-reportinglogs http://xxx.xxx.xxx.xxx.xxx/webdav/backup/linux-innovaphone-reporting-logs-#i-#d-#b10.tar.gz 
# commands only Saturdays and Sundays at 00am executed.
times day:6,7 hour:00
saveinnovaphone-reportingcfgs http://xxx.xxx.xxx.xxx.xxx/webdav/backup/linux-innovaphone-reporting-cfgs-#i-#d-#b10.tar.gz 
saveinnovaphone-reportinglogs http://xxx.xxx.xxx.xxx.xxx/webdav/backup/linux-innovaphone-reporting-logs-#i-#d-#b10.tar.gz 
</pre>

* day goes from 1 (Monday) to 7 (Sunday). 
* hour goes from 00 to 23. 

You can specify multiple times commands to override the last one. 

=====Backup file name macros=====

You can use some macros for the backup filename:

* #i - will be replaced with the current IP address
* #m - will be replaced with the current MAC address
* #d - will be replaced with date/time in format Ymd-His (20110231-111010)
* #bxx - will be replaced with the current backup index, whilst xx is the maximum index

====Save configuration files/data====

Open this link to see all available files/data/logs to download them manually.

Password files for web server authentication won't be saved!

====Restore configuration files/data====

Open this link to restore all available files/data.

Password files for web server authentication won't be restored!

===Mails===

The Application Platform contains a mail client which speaks smtp (mutt+sendmail). This is used by default. 
Mail could be also configured to send mails via an external server (smtp relay).

[[Image:smtp.png]]

==Applications==

===List===

A list of all currently installed applications. 
If an application has an own web interface, you can reach it by using the application name link. 

====Uninstall====
Use the uninstall link in the list to uninstall an application.

===Upload/Update===

Here all new applications, application updates and application platform updates are installed. 
After uploading the file, the installation will start automatically and the installation process will be shown. The page refreshes until the installation has finished.

==Diagnostics==

===Logs===

Here you can view, download or clear the available log files from the application platform or from installed applications. 
You can also download all log files at once (this archiv also contains older versions from the log files).

===RPCAP===

Enable/disable RPCAP for use with Wireshark. 
A link will be display, which you can use within Wireshark.

===Alarm Server===

Configure an innovaphone device as alarm server:

* '''ip''': IP address of the innovaphone device
* ['''port''']
* ['''user''']: user for authentication to the alarm server
* ['''password''']
* ['''https''']: use https to send the alarm

Options in '''[]''' are optional.

Alarms from installed applications or the application platform itself will be sent to this configured server.

===Status===

View the disk usage.

===Reset===
====IPxx10====

Shutdown the application platform. You'll have to restart it over the IPxx10 gateway.

====VMWare====

Shutdown the application platform or reboot it.

==Use as Log or Alarm Server==

You can use the application platform as a server for innovaphone logs. 
Configure Local-AP(-s)/Remote-AP(-s) on [[Reference9:Services/Logging]].
 
The following scripts are used to retrieve the logs/alarms:
* logs: /ap/log.fcgi
* alarms: /ap/alarm.fcgi

So you can make the path '''/ap''' public on the ''Linux Web Server'' or you configure an authenticated URL for these files/this path on your ''innovaphone gateway''. 

If you configure an authenticated URL, don't forget to configure port 80 or port 443 for secure transport (Remote-AP-S) like
https://111.111.111.111:443/ap or http://111.111.111.111:80/ap

==Use as File/VM-Server==

You can use the application platform as file server, e.g. for udpate scripts, voicemail etc. 
You can access the server with a webdav client via '''http(s)://Linux-IP/webdav''' 
Public access to certain paths etc. can be configured under the [[Reference9:Concept_Linux_Application_Platform#Web_Server | web server configuration]].

==Enable further Tracing==
There are different trace options, which can be enabled by calling a certain php script: 
https://LINUX-IP/trace.php?level=63

The level is calculated by the addition of one or multiple of the following trace options:

{| border=1
|| '''Option''' || '''To add'''
|-
|| TRACE_STD || 1
|-
|| TRACE_DB || 2
|-
|| TRACE_TIME || 4
|-
|| TRACE_CALL_FLOW_TOTAL || 8
|-
|| TRACE_CALL_FLOW || 16
|-
|| TRACE_PARSE_CFG || 32
|-
|}

So currently all trace options are enabled with the level '''63'''.

==Appendix==
===Creating own applications===
See [[Reference9:Concept Linux Application]]

===Tools===

====NetDrive====

[http://www.heise.de/software/download/netdrive/55134 NetDrive] is a usefull webdav client, which can be used to access webdav of the innovaphone application platform.

====Putty====

[http://www.putty.org/ Putty] is SSH client to connect to the linux application platform.

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

===Manual Debian Upgrade===
If you have installed one of our upgrade hotfixes and you had installed packages, which weren't included in innovaphone applications, the upgrade of some packages might have failed. You will see a warning message on your application platform. Something like:

<code type="text">
The following packages couldn't be upgraded due to missing dependencies: php5-cgi php5-cli
Take a look at our wiki to see, what you have to do now!
</code>

Now you have to perfom some actions yourself:
* make sure, your Linux Application Platform has internet access
* login with a terminal client like Putty
* start 'apt-get update'
* start 'apt-get install php5-cgi php5-cli' (list the packages of the warning message)
* delete the file /var/www/innovaphone/log/missing_packages.log to clear the warning message:
** rm /var/www/innovaphone/log/missing_packages.log

Your installation should be now up to date again.

===Configuring a new Kernel===
If you have installed a hotfix with a new kernel, you will see a warning message on your application platform. Something like:

<code type="text">
You're not running the latest kernel Image-6010-3.4.10!
Take a look at our wiki to see, what you have to do now!
</code>

To change to the new kernel, you have to reconfigure something on your device, where the CF card is plugged in.
* First shutdown your Linux (see [[ Reference9:Concept_Linux_Application_Platform#IPxx10 ]])
* Stop Linux under [[ Reference9:Linux/General ]]
* Configure the latest kernel file (currently <code>Image-6010-3.4.10</code>) under [[ Reference9:Linux/General ]] '''Linux kernel file'''
* Start Linux under [[ Reference9:Linux/General ]]

==Known Issues==
===Separate authentication for innovaphone-reporting===
If you configured a separate authentication, it depends on the used browser, whether you have to re-authenticate on switching between the root web and the innovaphone-reporting web access or not.

===Refreshing issue on hotfix installation===
[[ Reference9:Concept_Linux_Application_Platform#Refreshing_issue_on_installation | See here. ]]

===Kernel Update in VM Platform===
The installation of a new kernel fails and this process leaves the system unstable, not being able to install any more debian packages. Hotfix installations will probably fail.

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

Reference9:Concept Linux Application Platform

2012-11-01T10:22:46Z

Ole: /* Web Server */

==Introduction==

The innovaphone Linux Application Platform permits to install innovaphone or custom applications for certain purposes, like Reporting or a Fax Server. 
It also allows to backup/restore configuration files, uninstall applications or see and backup logs. 
 
The Linux distribution Debian 6 (Squeeze) is used and linux kernel is 2.6.35.4. 
 
The architecture of the platform is armel. 
 

==Requirements==

There are two ways to use the innovaphone Linux Application Platform:

===On an IPxx10 Gateway===
* An IP0010, IP3010 or IP6010 Gateway
* Firmware Version 9
* A compact flash card with UDMA support (minimum 4 GB)
** We recommend SanDisk Extreme with UDMA and 90 MB/s or above

===As a Virtual Machine===
* VMWare Player/VMWare Workstation

==Installation==

Download the latest Linux Application Platform from [https://download.innovaphone.com download.innovaphone.com ]. 
You can download and install two different packages:

===Default Credentials===
* Web/Webdav: '''admin'''/'''linux'''
* Root-Login (e.g. with Putty): '''root'''/'''iplinux'''

===Disk space usage after first time installation===

====IPxx10 Gateways====

* /dev/sda1: 32 MB (fat32 partition with kernel, which is started by the IPxx10)
* /dev/sda2: 450 MB (ext2 initial installation partition)
* /dev/sda3: 120 MB (swap partition)
* /dev/sda4: 600 MB / xx GB depending of the size of the used CF card (ext4 partition, which is actually booted)

All in all about 1.2 GB are already in use after the initial installation.

====VMWare====

* /dev/sda1: 665 MB (ext2 initial installation partition)
* /dev/sda2: 120 MB (swap partition)
* /dev/sda3: 680 MB / xx GB depending of your pre installation configuration (ext3 partition, which is actually booted)

All in all about 1.5 GB are already in use after the initial installation.

===Linux Application Platform (IPxx10 Gateways)===

It is recommended to use CF-Cards with sizes of 8GB or more and the card '''must''' support UDMA! 
* Enable Linux under Linux General.
[[image:IPxx10_Linux_-_enable.png]]
* Enable Proxy-ARP on ETH0 or ETH1 [[ Reference:Configuration/ETH/IP|here ]]
* Decompress the downloaded package. You should have an image file like <code>linux_ipxx10_armel.img</code> now.
* Upload the decompressed file over the gateways web interface under [[ Reference9:General/Compact-Flash/Image ]]. Unmount the CF card if necessary. Select "Part 1" before starting the upload!
[[image:IPxx10_Linux_-_upload_image.png‎]]
* Reset the box (which also activates the config change of step 1).
* Configure IP under [[ Reference9:Linux/IP ]]: select either "Disabled" to assign a static IP or ETH0/ETH1 to receive an IP-Address from DHCP-Server behind ETH0 or ETH1.
* Configure the kernel file, which you find under [[ Reference9:General/Compact-Flash/General#Browse_CF_Content ]] on [[ Reference9:Linux/General ]] '''Linux kernel file''' (Currently <code>Image-6010-3.4.10</code>)
* Configure <code>root=/dev/sda2</code> under [[ Reference9:Linux/General ]] '''Kernel command line'''.
* If you want, configure the autostart flag.
* Submit your changes.
* Click the [[ Reference9:Linux/General ]] '''Start'''-Link. The page refreshes until Linux gets an IP and then tries to get a link to the Linux Web Server, which can take some time for the first time installation (~ 5 minutes to 2 hours).
[[Image:device_conf.jpg]]
* Open the Linux Web Server to see the installation progress (which might take several minutes too). The default credentials are '''admin'''/'''linux'''.
[[Image:installation.jpg]]
* Enter the innovaphone device admin credentials when the installation has finished. Now wait until the page refrehses. The web server credentials are now the innovaphone device admin credentials.
* Linux install has finished.
* You will see now <code>root=/dev/sda4</code> under [[ Reference9:Linux/General ]] since Linux is running in on the fourth partition. You shouldn't change that unless you want to install Linux again.

===Linux Application Platform (VMWare)===

* Decompress the downloaded archive. You should have two files: '''IP-Debian.vmx''' and '''IP-Debian.vmdk'''.
* Now you have two possibilities (example for VMWare Player, VMWare Workstation should be similar):
** If you want to assign more than 4 GB virtual flash (8 GB since Hotfix 7):
*** Do '''not''' directly start/doubleclick the vmx file!
*** Start the VMware Player and Open the vmx file with '''Open a Virtual Machine'''.
*** Open '''Edit virtual machine settings'''.
*** Select the hard disk and '''Expand''' it under '''Utilities''' to the wished size.
*** Apply the change and klick '''Play virtual machine'''.
** If 4 GB (8 GB since Hotfix 7) are enough, simply double click the vmx file and Linux will start.
* The first time, a script will automatically configure a new partition, the web server etc., which will take some time. The waiting time depends on the CPU of the computer running the vmware player. In some cases the waiting time can be up to 30 minutes, in most cases the installation finishes in about 2-5 minutes.
* In the meantime, fetch your IP from the VMWare Player screen or login as root and get your IP address with the command '''ifconfig'''.
* Login to the web server to see the installation progress (it may take some minutes until the web server is up).
* Linux will restart automatically after the first time installation has finished.
* Linux install has finished.

===Hotfix Installation===
If you have already installed the latest version of the Linux Application Platform, simply download the Linux...HotfixIncremental for your platform (VM or IPxx10) or if you have missed some hotfixes, download the Linux...HotfixCumulative archive, which contains all hotfixes since hotfix1.
 
 
Upload this hotfix archive [[Reference9:Concept_Linux_Application_Platform#Upload.2FUpdate|here]].

====Refreshing issue on installation====
You might get a PHP error when the browser is refreshing during the installation. Just refresh (F5) the page and you'll get the installation progress again.

===Static IP?===
The Linux itself '''must''' be running in DHCP client mode to run properly. If you want to assign a static IP address, do it like this:

* On an IPxx10: assign a static IP under [[ Reference9:Linux/IP ]]
* On a VMWare: assign a static IP in your local DHCP server for your MAC address defined in the *.vmx file

==Administration==

===General===

====Change the root credentials====

Here you can change the credentials of the Linux root user. 
Default password: '''iplinux'''

====Configure Authenticated URLs====

Configure credentials for authenticated URLs. These credentials will be used in automatic backups. 
You can add/remove Urls with the '''+''' and '''-''' at the right side of the list.

* URL: the URL, e.g. https://172.16.123.123/backup
* User: the user for this URL
* Password: the password for this URL

====Configure NTP server====

Configures a NTP server.

* NTP Server: the IP of the NTP Server

====Change Timezone====

Default is Europe/Berlin but you can change that to a valid timezone (an error is given if timezone not present). 

====Change postgresql admin password====

If innovaphone Reporting is installed, you can configure another password for the postgres admin user. 
Default password: '''postgres'''.

===Web Server===

We use lighttpd version 1.4.28. The linux web server user is '''www-data''' and group user also '''www-data'''. Root directory for the web-server is '''/var/www/innovaphone'''. This information is mainly relevant if you plan to develope custom applications and integrate them into linux application platform.

Default users and password for the different levels on the Linux application plattform (see figure below):
[[image:Linux_Application_hierarki.PNG]]

====Change web server properties and public access to the web/webdav====
* Force HTTPS: enables redirection for HTTP to HTTPS
* Public Web Paths: these paths are not password protected, e.g. '/ap'
* Public Webdav Paths: these webdav paths are not password protected, e.g. '/backup'
** These paths are by default readonly. You can set the 'Write' flag to make the path also writable. This flag will be anyway ignored if credentials are provided. 

Enter a single '/' for a public root directory. All sub directories and files will be also public then. 
If you enter e.g. '/update/', the directory 'update' and all sub directories/files will be public. 
If you enter e.g. '/update', only the directory 'update' and its files will be public.

====Change the Linux web server credentials====

Here you can change the credentials for Web Server access.

If running VMWare, default password is '''linux'''. If running IPXX10, password is the one entered at the end of first installation (admin password of the device where linux is running)

====Change the Linux webdav access credentials====

Here you can change the credentials for webdav access.

If running VMWare, default password is '''linux'''. If running IPXX10, password is the one entered at the end of first installation (admin password of the device where linux is running)

====Change application access credentials====

If you have installed an application, which has the lighttpd-auth property set in its configuration file, you can configure a separate user/password for the applications web site. 
If you want to disable the separate authentication, leave the '''user''' field empty and enter the currently configured password. The authentication will be the same as the root web server authentication afterwards. 
One can just login on the application web site with this access.

A configured access overrides a configured public web path to '/apps/application-name'!

===Certificates===

The current server certificate installed on the web server is shown here. A self signed certificate, innovaphone-linux, is installed by default. It is recommended to change it with your own certificate.

It is also possible to trust or reject other certificates.

===Backup===

The web server can be configured to poll a Command File URL (on a web server). 
The backup process is similar to [[Reference9:Services/Update]]. 

An alarm server can be also configured to receive alarms during an automatic backup: [[ #Alarm_Server | Alarm Server under Diagnostics ]].

At the bottom you will see a list of the current automatic backup serials from the Command File URL and the log of the last automatic backups.

[[Image:backup_restore.jpg]]

====Command File====

Example:
saveinnovaphonecfgs http://172.16.123.123/webdav/backup/cfgs-#i-#b10.tar.gz

The available default commands are:

=====saveinnovaphonecfgs=====

Saves all neccessary configuration files (no application specific files) as a tar gz archive (so you should use .tar.gz as ending).

=====saveinnovaphonelogs=====

Saves all available (also application related) log files as a tar gz archive (so you should use .tar.gz as ending).

=====times=====
Executes the following command(s) only, if the specified time matches and only once per hour (independent of poll timeout value). 
Example:

<pre>
# both commands always executed
saveinnovaphonelogs http://xxx.xxx.xxx.xxx.xxx/webdav/backup/linux-logs-#i-#m-#b10.tar.gz 
saveinnovaphonecfgs http://xxx.xxx.xxx.xxx.xxx/webdav/backup/linux-cfg-#i-#m-#b10.tar.gz 
# commands only from monday till saturday at 10am and 11am executed.
times day:1,2,3,4,5 hour:10,11
saveinnovaphone-reportingcfgs http://xxx.xxx.xxx.xxx.xxx/webdav/backup/linux-innovaphone-reporting-cfgs-#i-#d-#b10.tar.gz 
saveinnovaphone-reportinglogs http://xxx.xxx.xxx.xxx.xxx/webdav/backup/linux-innovaphone-reporting-logs-#i-#d-#b10.tar.gz 
# commands only Saturdays and Sundays at 00am executed.
times day:6,7 hour:00
saveinnovaphone-reportingcfgs http://xxx.xxx.xxx.xxx.xxx/webdav/backup/linux-innovaphone-reporting-cfgs-#i-#d-#b10.tar.gz 
saveinnovaphone-reportinglogs http://xxx.xxx.xxx.xxx.xxx/webdav/backup/linux-innovaphone-reporting-logs-#i-#d-#b10.tar.gz 
</pre>

* day goes from 1 (Monday) to 7 (Sunday). 
* hour goes from 00 to 23. 

You can specify multiple times commands to override the last one. 

=====Backup file name macros=====

You can use some macros for the backup filename:

* #i - will be replaced with the current IP address
* #m - will be replaced with the current MAC address
* #d - will be replaced with date/time in format Ymd-His (20110231-111010)
* #bxx - will be replaced with the current backup index, whilst xx is the maximum index

====Save configuration files/data====

Open this link to see all available files/data/logs to download them manually.

Password files for web server authentication won't be saved!

====Restore configuration files/data====

Open this link to restore all available files/data.

Password files for web server authentication won't be restored!

===Mails===

The Application Platform contains a mail client which speaks smtp (mutt+sendmail). This is used by default. 
Mail could be also configured to send mails via an external server (smtp relay).

[[Image:smtp.png]]

==Applications==

===List===

A list of all currently installed applications. 
If an application has an own web interface, you can reach it by using the application name link. 

====Uninstall====
Use the uninstall link in the list to uninstall an application.

===Upload/Update===

Here all new applications, application updates and application platform updates are installed. 
After uploading the file, the installation will start automatically and the installation process will be shown. The page refreshes until the installation has finished.

==Diagnostics==

===Logs===

Here you can view, download or clear the available log files from the application platform or from installed applications. 
You can also download all log files at once (this archiv also contains older versions from the log files).

===RPCAP===

Enable/disable RPCAP for use with Wireshark. 
A link will be display, which you can use within Wireshark.

===Alarm Server===

Configure an innovaphone device as alarm server:

* '''ip''': IP address of the innovaphone device
* ['''port''']
* ['''user''']: user for authentication to the alarm server
* ['''password''']
* ['''https''']: use https to send the alarm

Options in '''[]''' are optional.

Alarms from installed applications or the application platform itself will be sent to this configured server.

===Status===

View the disk usage.

===Reset===
====IPxx10====

Shutdown the application platform. You'll have to restart it over the IPxx10 gateway.

====VMWare====

Shutdown the application platform or reboot it.

==Use as Log or Alarm Server==

You can use the application platform as a server for innovaphone logs. 
Configure Local-AP(-s)/Remote-AP(-s) on [[Reference9:Services/Logging]].
 
The following scripts are used to retrieve the logs/alarms:
* logs: /ap/log.fcgi
* alarms: /ap/alarm.fcgi

So you can make the path '''/ap''' public on the ''Linux Web Server'' or you configure an authenticated URL for these files/this path on your ''innovaphone gateway''. 

If you configure an authenticated URL, don't forget to configure port 80 or port 443 for secure transport (Remote-AP-S) like
https://111.111.111.111:443/ap or http://111.111.111.111:80/ap

==Use as File/VM-Server==

You can use the application platform as file server, e.g. for udpate scripts, voicemail etc. 
You can access the server with a webdav client via '''http(s)://Linux-IP/webdav''' 
Public access to certain paths etc. can be configured under the [[Reference9:Concept_Linux_Application_Platform#Web_Server | web server configuration]].

==Enable further Tracing==
There are different trace options, which can be enabled by calling a certain php script: 
https://LINUX-IP/trace.php?level=63

The level is calculated by the addition of one or multiple of the following trace options:

{| border=1
|| '''Option''' || '''To add'''
|-
|| TRACE_STD || 1
|-
|| TRACE_DB || 2
|-
|| TRACE_TIME || 4
|-
|| TRACE_CALL_FLOW_TOTAL || 8
|-
|| TRACE_CALL_FLOW || 16
|-
|| TRACE_PARSE_CFG || 32
|-
|}

So currently all trace options are enabled with the level '''63'''.

==Appendix==
===Creating own applications===
See [[Reference9:Concept Linux Application]]

===Tools===

====NetDrive====

[http://www.heise.de/software/download/netdrive/55134 NetDrive] is a usefull webdav client, which can be used to access webdav of the innovaphone application platform.

====Putty====

[http://www.putty.org/ Putty] is SSH client to connect to the linux application platform.

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

===Manual Debian Upgrade===
If you have installed one of our upgrade hotfixes and you had installed packages, which weren't included in innovaphone applications, the upgrade of some packages might have failed. You will see a warning message on your application platform. Something like:

<code type="text">
The following packages couldn't be upgraded due to missing dependencies: php5-cgi php5-cli
Take a look at our wiki to see, what you have to do now!
</code>

Now you have to perfom some actions yourself:
* make sure, your Linux Application Platform has internet access
* login with a terminal client like Putty
* start 'apt-get update'
* start 'apt-get install php5-cgi php5-cli' (list the packages of the warning message)
* delete the file /var/www/innovaphone/log/missing_packages.log to clear the warning message:
** rm /var/www/innovaphone/log/missing_packages.log

Your installation should be now up to date again.

===Configuring a new Kernel===
If you have installed a hotfix with a new kernel, you will see a warning message on your application platform. Something like:

<code type="text">
You're not running the latest kernel Image-6010-3.4.10!
Take a look at our wiki to see, what you have to do now!
</code>

To change to the new kernel, you have to reconfigure something on your device, where the CF card is plugged in.
* First shutdown your Linux (see [[ Reference9:Concept_Linux_Application_Platform#IPxx10 ]])
* Stop Linux under [[ Reference9:Linux/General ]]
* Configure the latest kernel file (currently <code>Image-6010-3.4.10</code>) under [[ Reference9:Linux/General ]] '''Linux kernel file'''
* Start Linux under [[ Reference9:Linux/General ]]

==Known Issues==
===Separate authentication for innovaphone-reporting===
If you configured a separate authentication, it depends on the used browser, whether you have to re-authenticate on switching between the root web and the innovaphone-reporting web access or not.

===Refreshing issue on hotfix installation===
[[ Reference9:Concept_Linux_Application_Platform#Refreshing_issue_on_installation | See here. ]]

===Kernel Update in VM Platform===
The installation of a new kernel fails and this process leaves the system unstable, not being able to install any more debian packages. Hotfix installations will probably fail.

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

File:Linux Application hierarki.PNG

2012-11-01T10:14:50Z

Ole: Default user names and passwords for the different levels of the Linux application platform.

Default user names and passwords for the different levels of the Linux application platform.

Reference9:Concept Linux Application Platform

2012-10-31T21:59:02Z

Ole: /* Linux Application Platform (IPxx10 Gateways) */

==Introduction==

The innovaphone Linux Application Platform permits to install innovaphone or custom applications for certain purposes, like Reporting or a Fax Server. 
It also allows to backup/restore configuration files, uninstall applications or see and backup logs. 
 
The Linux distribution Debian 6 (Squeeze) is used and linux kernel is 2.6.35.4. 
 
The architecture of the platform is armel. 
 

==Requirements==

There are two ways to use the innovaphone Linux Application Platform:

===On an IPxx10 Gateway===
* An IP0010, IP3010 or IP6010 Gateway
* Firmware Version 9
* A compact flash card with UDMA support (minimum 4 GB)
** We recommend SanDisk Extreme with UDMA and 90 MB/s or above

===As a Virtual Machine===
* VMWare Player/VMWare Workstation

==Installation==

Download the latest Linux Application Platform from [https://download.innovaphone.com download.innovaphone.com ]. 
You can download and install two different packages:

===Default Credentials===
* Web/Webdav: '''admin'''/'''linux'''
* Root-Login (e.g. with Putty): '''root'''/'''iplinux'''

===Disk space usage after first time installation===

====IPxx10 Gateways====

* /dev/sda1: 32 MB (fat32 partition with kernel, which is started by the IPxx10)
* /dev/sda2: 450 MB (ext2 initial installation partition)
* /dev/sda3: 120 MB (swap partition)
* /dev/sda4: 600 MB / xx GB depending of the size of the used CF card (ext4 partition, which is actually booted)

All in all about 1.2 GB are already in use after the initial installation.

====VMWare====

* /dev/sda1: 665 MB (ext2 initial installation partition)
* /dev/sda2: 120 MB (swap partition)
* /dev/sda3: 680 MB / xx GB depending of your pre installation configuration (ext3 partition, which is actually booted)

All in all about 1.5 GB are already in use after the initial installation.

===Linux Application Platform (IPxx10 Gateways)===

It is recommended to use CF-Cards with sizes of 8GB or more and the card '''must''' support UDMA! 
* Enable Linux under Linux General.
[[image:IPxx10_Linux_-_enable.png]]
* Enable Proxy-ARP on ETH0 or ETH1 [[ Reference:Configuration/ETH/IP|here ]]
* Decompress the downloaded package. You should have an image file like <code>linux_ipxx10_armel.img</code> now.
* Upload the decompressed file over the gateways web interface under [[ Reference9:General/Compact-Flash/Image ]]. Unmount the CF card if necessary. Select "Part 1" before starting the upload!
[[image:IPxx10_Linux_-_upload_image.png‎]]
* Reset the box (which also activates the config change of step 1).
* Configure IP under [[ Reference9:Linux/IP ]]: select either "Disabled" to assign a static IP or ETH0/ETH1 to receive an IP-Address from DHCP-Server behind ETH0 or ETH1.
* Configure the kernel file, which you find under [[ Reference9:General/Compact-Flash/General#Browse_CF_Content ]] on [[ Reference9:Linux/General ]] '''Linux kernel file''' (Currently <code>Image-6010-3.4.10</code>)
* Configure <code>root=/dev/sda2</code> under [[ Reference9:Linux/General ]] '''Kernel command line'''.
* If you want, configure the autostart flag.
* Submit your changes.
* Click the [[ Reference9:Linux/General ]] '''Start'''-Link. The page refreshes until Linux gets an IP and then tries to get a link to the Linux Web Server, which can take some time for the first time installation (~ 5 minutes to 2 hours).
[[Image:device_conf.jpg]]
* Open the Linux Web Server to see the installation progress (which might take several minutes too). The default credentials are '''admin'''/'''linux'''.
[[Image:installation.jpg]]
* Enter the innovaphone device admin credentials when the installation has finished. Now wait until the page refrehses. The web server credentials are now the innovaphone device admin credentials.
* Linux install has finished.
* You will see now <code>root=/dev/sda4</code> under [[ Reference9:Linux/General ]] since Linux is running in on the fourth partition. You shouldn't change that unless you want to install Linux again.

===Linux Application Platform (VMWare)===

* Decompress the downloaded archive. You should have two files: '''IP-Debian.vmx''' and '''IP-Debian.vmdk'''.
* Now you have two possibilities (example for VMWare Player, VMWare Workstation should be similar):
** If you want to assign more than 4 GB virtual flash (8 GB since Hotfix 7):
*** Do '''not''' directly start/doubleclick the vmx file!
*** Start the VMware Player and Open the vmx file with '''Open a Virtual Machine'''.
*** Open '''Edit virtual machine settings'''.
*** Select the hard disk and '''Expand''' it under '''Utilities''' to the wished size.
*** Apply the change and klick '''Play virtual machine'''.
** If 4 GB (8 GB since Hotfix 7) are enough, simply double click the vmx file and Linux will start.
* The first time, a script will automatically configure a new partition, the web server etc., which will take some time. The waiting time depends on the CPU of the computer running the vmware player. In some cases the waiting time can be up to 30 minutes, in most cases the installation finishes in about 2-5 minutes.
* In the meantime, fetch your IP from the VMWare Player screen or login as root and get your IP address with the command '''ifconfig'''.
* Login to the web server to see the installation progress (it may take some minutes until the web server is up).
* Linux will restart automatically after the first time installation has finished.
* Linux install has finished.

===Hotfix Installation===
If you have already installed the latest version of the Linux Application Platform, simply download the Linux...HotfixIncremental for your platform (VM or IPxx10) or if you have missed some hotfixes, download the Linux...HotfixCumulative archive, which contains all hotfixes since hotfix1.
 
 
Upload this hotfix archive [[Reference9:Concept_Linux_Application_Platform#Upload.2FUpdate|here]].

====Refreshing issue on installation====
You might get a PHP error when the browser is refreshing during the installation. Just refresh (F5) the page and you'll get the installation progress again.

===Static IP?===
The Linux itself '''must''' be running in DHCP client mode to run properly. If you want to assign a static IP address, do it like this:

* On an IPxx10: assign a static IP under [[ Reference9:Linux/IP ]]
* On a VMWare: assign a static IP in your local DHCP server for your MAC address defined in the *.vmx file

==Administration==

===General===

====Change the root credentials====

Here you can change the credentials of the Linux root user. 
Default password: '''iplinux'''

====Configure Authenticated URLs====

Configure credentials for authenticated URLs. These credentials will be used in automatic backups. 
You can add/remove Urls with the '''+''' and '''-''' at the right side of the list.

* URL: the URL, e.g. https://172.16.123.123/backup
* User: the user for this URL
* Password: the password for this URL

====Configure NTP server====

Configures a NTP server.

* NTP Server: the IP of the NTP Server

====Change Timezone====

Default is Europe/Berlin but you can change that to a valid timezone (an error is given if timezone not present). 

====Change postgresql admin password====

If innovaphone Reporting is installed, you can configure another password for the postgres admin user. 
Default password: '''postgres'''.

===Web Server===

We use lighttpd version 1.4.28. The linux web server user is '''www-data''' and group user also '''www-data'''. Root directory for the web-server is '''/var/www/innovaphone'''. This information is mainly relevant if you plan to develope custom applications and integrate them into linux application platform.

====Change web server properties and public access to the web/webdav====
* Force HTTPS: enables redirection for HTTP to HTTPS
* Public Web Paths: these paths are not password protected, e.g. '/ap'
* Public Webdav Paths: these webdav paths are not password protected, e.g. '/backup'
** These paths are by default readonly. You can set the 'Write' flag to make the path also writable. This flag will be anyway ignored if credentials are provided. 

Enter a single '/' for a public root directory. All sub directories and files will be also public then. 
If you enter e.g. '/update/', the directory 'update' and all sub directories/files will be public. 
If you enter e.g. '/update', only the directory 'update' and its files will be public.

====Change the Linux web server credentials====

Here you can change the credentials for Web Server access.

If running VMWare, default password is '''linux'''. If running IPXX10, password is the one entered at the end of first installation (admin password of the device where linux is running)

====Change the Linux webdav access credentials====

Here you can change the credentials for webdav access.

If running VMWare, default password is '''linux'''. If running IPXX10, password is the one entered at the end of first installation (admin password of the device where linux is running)

====Change application access credentials====

If you have installed an application, which has the lighttpd-auth property set in its configuration file, you can configure a separate user/password for the applications web site. 
If you want to disable the separate authentication, leave the '''user''' field empty and enter the currently configured password. The authentication will be the same as the root web server authentication afterwards. 
One can just login on the application web site with this access.

A configured access overrides a configured public web path to '/apps/application-name'!

===Certificates===

The current server certificate installed on the web server is shown here. A self signed certificate, innovaphone-linux, is installed by default. It is recommended to change it with your own certificate.

It is also possible to trust or reject other certificates.

===Backup===

The web server can be configured to poll a Command File URL (on a web server). 
The backup process is similar to [[Reference9:Services/Update]]. 

An alarm server can be also configured to receive alarms during an automatic backup: [[ #Alarm_Server | Alarm Server under Diagnostics ]].

At the bottom you will see a list of the current automatic backup serials from the Command File URL and the log of the last automatic backups.

[[Image:backup_restore.jpg]]

====Command File====

Example:
saveinnovaphonecfgs http://172.16.123.123/webdav/backup/cfgs-#i-#b10.tar.gz

The available default commands are:

=====saveinnovaphonecfgs=====

Saves all neccessary configuration files (no application specific files) as a tar gz archive (so you should use .tar.gz as ending).

=====saveinnovaphonelogs=====

Saves all available (also application related) log files as a tar gz archive (so you should use .tar.gz as ending).

=====times=====
Executes the following command(s) only, if the specified time matches and only once per hour (independent of poll timeout value). 
Example:

<pre>
# both commands always executed
saveinnovaphonelogs http://xxx.xxx.xxx.xxx.xxx/webdav/backup/linux-logs-#i-#m-#b10.tar.gz 
saveinnovaphonecfgs http://xxx.xxx.xxx.xxx.xxx/webdav/backup/linux-cfg-#i-#m-#b10.tar.gz 
# commands only from monday till saturday at 10am and 11am executed.
times day:1,2,3,4,5 hour:10,11
saveinnovaphone-reportingcfgs http://xxx.xxx.xxx.xxx.xxx/webdav/backup/linux-innovaphone-reporting-cfgs-#i-#d-#b10.tar.gz 
saveinnovaphone-reportinglogs http://xxx.xxx.xxx.xxx.xxx/webdav/backup/linux-innovaphone-reporting-logs-#i-#d-#b10.tar.gz 
# commands only Saturdays and Sundays at 00am executed.
times day:6,7 hour:00
saveinnovaphone-reportingcfgs http://xxx.xxx.xxx.xxx.xxx/webdav/backup/linux-innovaphone-reporting-cfgs-#i-#d-#b10.tar.gz 
saveinnovaphone-reportinglogs http://xxx.xxx.xxx.xxx.xxx/webdav/backup/linux-innovaphone-reporting-logs-#i-#d-#b10.tar.gz 
</pre>

* day goes from 1 (Monday) to 7 (Sunday). 
* hour goes from 00 to 23. 

You can specify multiple times commands to override the last one. 

=====Backup file name macros=====

You can use some macros for the backup filename:

* #i - will be replaced with the current IP address
* #m - will be replaced with the current MAC address
* #d - will be replaced with date/time in format Ymd-His (20110231-111010)
* #bxx - will be replaced with the current backup index, whilst xx is the maximum index

====Save configuration files/data====

Open this link to see all available files/data/logs to download them manually.

Password files for web server authentication won't be saved!

====Restore configuration files/data====

Open this link to restore all available files/data.

Password files for web server authentication won't be restored!

===Mails===

The Application Platform contains a mail client which speaks smtp (mutt+sendmail). This is used by default. 
Mail could be also configured to send mails via an external server (smtp relay).

[[Image:smtp.png]]

==Applications==

===List===

A list of all currently installed applications. 
If an application has an own web interface, you can reach it by using the application name link. 

====Uninstall====
Use the uninstall link in the list to uninstall an application.

===Upload/Update===

Here all new applications, application updates and application platform updates are installed. 
After uploading the file, the installation will start automatically and the installation process will be shown. The page refreshes until the installation has finished.

==Diagnostics==

===Logs===

Here you can view, download or clear the available log files from the application platform or from installed applications. 
You can also download all log files at once (this archiv also contains older versions from the log files).

===RPCAP===

Enable/disable RPCAP for use with Wireshark. 
A link will be display, which you can use within Wireshark.

===Alarm Server===

Configure an innovaphone device as alarm server:

* '''ip''': IP address of the innovaphone device
* ['''port''']
* ['''user''']: user for authentication to the alarm server
* ['''password''']
* ['''https''']: use https to send the alarm

Options in '''[]''' are optional.

Alarms from installed applications or the application platform itself will be sent to this configured server.

===Status===

View the disk usage.

===Reset===
====IPxx10====

Shutdown the application platform. You'll have to restart it over the IPxx10 gateway.

====VMWare====

Shutdown the application platform or reboot it.

==Use as Log or Alarm Server==

You can use the application platform as a server for innovaphone logs. 
Configure Local-AP(-s)/Remote-AP(-s) on [[Reference9:Services/Logging]].
 
The following scripts are used to retrieve the logs/alarms:
* logs: /ap/log.fcgi
* alarms: /ap/alarm.fcgi

So you can make the path '''/ap''' public on the ''Linux Web Server'' or you configure an authenticated URL for these files/this path on your ''innovaphone gateway''. 

If you configure an authenticated URL, don't forget to configure port 80 or port 443 for secure transport (Remote-AP-S) like
https://111.111.111.111:443/ap or http://111.111.111.111:80/ap

==Use as File/VM-Server==

You can use the application platform as file server, e.g. for udpate scripts, voicemail etc. 
You can access the server with a webdav client via '''http(s)://Linux-IP/webdav''' 
Public access to certain paths etc. can be configured under the [[Reference9:Concept_Linux_Application_Platform#Web_Server | web server configuration]].

==Enable further Tracing==
There are different trace options, which can be enabled by calling a certain php script: 
https://LINUX-IP/trace.php?level=63

The level is calculated by the addition of one or multiple of the following trace options:

{| border=1
|| '''Option''' || '''To add'''
|-
|| TRACE_STD || 1
|-
|| TRACE_DB || 2
|-
|| TRACE_TIME || 4
|-
|| TRACE_CALL_FLOW_TOTAL || 8
|-
|| TRACE_CALL_FLOW || 16
|-
|| TRACE_PARSE_CFG || 32
|-
|}

So currently all trace options are enabled with the level '''63'''.

==Appendix==
===Creating own applications===
See [[Reference9:Concept Linux Application]]

===Tools===

====NetDrive====

[http://www.heise.de/software/download/netdrive/55134 NetDrive] is a usefull webdav client, which can be used to access webdav of the innovaphone application platform.

====Putty====

[http://www.putty.org/ Putty] is SSH client to connect to the linux application platform.

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

===Manual Debian Upgrade===
If you have installed one of our upgrade hotfixes and you had installed packages, which weren't included in innovaphone applications, the upgrade of some packages might have failed. You will see a warning message on your application platform. Something like:

<code type="text">
The following packages couldn't be upgraded due to missing dependencies: php5-cgi php5-cli
Take a look at our wiki to see, what you have to do now!
</code>

Now you have to perfom some actions yourself:
* make sure, your Linux Application Platform has internet access
* login with a terminal client like Putty
* start 'apt-get update'
* start 'apt-get install php5-cgi php5-cli' (list the packages of the warning message)
* delete the file /var/www/innovaphone/log/missing_packages.log to clear the warning message:
** rm /var/www/innovaphone/log/missing_packages.log

Your installation should be now up to date again.

===Configuring a new Kernel===
If you have installed a hotfix with a new kernel, you will see a warning message on your application platform. Something like:

<code type="text">
You're not running the latest kernel Image-6010-3.4.10!
Take a look at our wiki to see, what you have to do now!
</code>

To change to the new kernel, you have to reconfigure something on your device, where the CF card is plugged in.
* First shutdown your Linux (see [[ Reference9:Concept_Linux_Application_Platform#IPxx10 ]])
* Stop Linux under [[ Reference9:Linux/General ]]
* Configure the latest kernel file (currently <code>Image-6010-3.4.10</code>) under [[ Reference9:Linux/General ]] '''Linux kernel file'''
* Start Linux under [[ Reference9:Linux/General ]]

==Known Issues==
===Separate authentication for innovaphone-reporting===
If you configured a separate authentication, it depends on the used browser, whether you have to re-authenticate on switching between the root web and the innovaphone-reporting web access or not.

===Refreshing issue on hotfix installation===
[[ Reference9:Concept_Linux_Application_Platform#Refreshing_issue_on_installation | See here. ]]

===Kernel Update in VM Platform===
The installation of a new kernel fails and this process leaves the system unstable, not being able to install any more debian packages. Hotfix installations will probably fail.

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