innovaphone wiki - User contributions [en]

Reference:IP1202/IP1203 DECT System

2015-12-10T11:21:06Z

Nfinzel: /* Training and Deployment */

This article describes the new IP1202 DECT system, differences to the IP1200, the migration policy and provides further helpful information.

==Applies To==
This information applies to:

*IP1202
*IP1202e
*IP61
*IP63

It touches:

*IP1200
*IP52
*IP54
*IP55
*IP56
*IP64

==Product Availability==

===IP-DECT base stations===

The '''IP1202''' (50-01202-001) is ready for order since April 2012.

The '''IP1202e''' (50-01202-003) with two external antenna connectors and two included dipole omni directional antennas will be ready for order in Q4/2012.

The '''IP1200''' can be ordered until supplies run out.

The '''defective IP1200''' devices can be repaired via RMA process until 05/2014.

===IP-DECT Repeater and Antennas===

The IP-DECT Repeater '''for IP1200''' and External Antennas can be ordered until 05/2014.

'''IP1202e''' includes two dipole omni directional antennas. Directional antennas have to be ordered separately depending on the use case. Following models will be available for order soon:
* DualDirectionalAntenna (50-01202-004)
* DirectionalSingleAntenna (50-01202-005)
* OmniDirectionalSingleAntenna (50-01202-006)

===DECT Handsets and Accessories===

The DECT handsets '''IP61''' (50-00061-001) and '''IP63''' (50-00063-001) are ready for order since April 2012.

The DECT handsets '''IP52, IP54, IP64, IP55, IP56''' can be ordered until 05/2014 ([http://www.innovaphone.com/en/press/newsletter/news-2014-05.html not available anymore]).

For the new DECT handsets IP61 and IP63 following chargers are available:
* simple charger (50-00060-002)
* programming charger (50-00060-003)(DC4-AAAB/3B) for administration purposes (via WinPDM)
Please be aware of the fact that chargers have to be ordered separately and are not part of the handset!

==Compatibility Statements==

===No Base Station and No Handset Compatibility===
The IP1202-based IP-DECT solution is '''not compatible''' to IP1200 based IP-DECT solution.

The ''old'' DECT handset IP50, IP52, IP54, IP55, IP56 will '''not operate''' on ''new'' IP1202-based IP-DECT system, since not only GAP compliance is required, but also CAP compliance (DECT external handover CAP-N.1).

The DECT handset '''must support GAP and CAP''' for operation on IP1202 based DECT system.

The ''new'' DECT handsets IP61 and IP63 will '''not operate''' on ''old'' IP1200 based IP-DECT system.

The ''new'' DECT base stations IP1202 and IP1202e '''can not be used''' to extend an existing ''old'' IP1200 based IP-DECT system.

=> This means '''NO HANDOVER''' between different systems (move with active call on a specific handset from an IP1200-system to an IP1202-based-system or vice versa)

=> This means '''NO ROAMING''' between different systems (usage of a specific handset in a non-compatible IP-DECT system - see above)

=== Mixed Ascom/innovaphone Environments ===
It is generally not supported to mix Ascom and innovaphone DECT products in a single installation, e.g.

* Combination of IP1202/IP1202e and Ascom IPBS2 base stations is neither allowed nor supported
* Usage of IP61/IP63 with Ascom IPBS2 based networks is not supported
* Usage of non-innovaphone handsets in IP1202 based networks is not supported
* Usage of IP61/IP63 with Ascom Alarm/Messaging Server (ex:UNITE) is not supported

The one and only exception to this is use of the Ascom d81 which may be operated in an IP1202 environment.

===No Multicell License Required===

The Multicell License is obsolete for IP1202-based IP-DECT systems.

For IP1202-based IP-DECT systems a SARI (Secondary Access Right Identity for DECT) certificate is required. The SARI activates an IP-DECT Master based on IP1202. One single SARI certificate is required for a single IP-DECT system, regardless how many base stations are used. Also for IP-DECT systems with one single base station a SARI certificate is required. The SARI certificate is not an innovaphone license and only required to make sure the DECT Radio Fixed Part Identity used in the DECT system is worldwide unique one.

A Multicell License can not be converted to a SARI certificate (and there is also no need to do so).

===Repeater and External Antennas===

There are '''no DECT repeaters available with IP1202''' based IP-DECT solution. Only IP1202-based base stations must be used.

The DECT repeaters for IP1200 are '''not compatible''' to IP1202/IP1202e.

The '''IP1202''' has no possibility to connect external antennas.

In case external antennas are required, the '''IP1202e''' has to be used. The IP1202e has '''no internal''' antennas.

===Certifications and Test Reports===
The innovaphone PBX was tested and certified by Ascom Wireless Solutions with Ascom IPBS based IP-DECT System, on which IP1202 is based (but is not the same product). A [[Media:Innovaphone PBX and Ascom IP-DECT certified by Ascom.pdf|Certificate]] and a [[Media:Innovaphone and ascom DECT Report.pdf|Test Report]] of this certification are available for download.

===Bluetooth Headset Support for IP63===

The IP63 DECT handset supports handsfree and headset profiles for Bluetooth.

Following headsets are tested by the manufacturer:

*3M Peltor WS XP
*Jabra EVOLVE 65
*Jabra MOTION
*Jabra STEALTH
*Jabra SUPREME
*Plantronics BlackBeat GO 2
*Plantronics Blackwire 710
*Plantronics M70
*Plantronics M90
*Plantronics ML20
*Plantronics Voyager Edge
*Plantronics Voyager Legend

==Training==

===DECT Training Kit===

To be able to attempt to the optional DECT Training Topic in the Advanced Training a DECT Training Kit must be ordered.

The DECT Training Kit contains:
*IP1202 x 2
*IP61
*IP63
*Charger for IP61/IP62/IP63
*USB-Programming Charger for IP61/IP63

This kit is referred to as ''Trainingspaket 2 (DECT)'' or ''Training Pack 2 (DECT)'' in the price list. Pleas note that this kit needs to present ''in addition'' to the regular training kit.

===Parallel usage of IP1200 and IP1202 IP-DECT systems===

The operation is only possible as two independent systems. No handover or roaming between the systems is possible. An IP1202-based system can and should synchronize the TDM clock with IP1200 based system to avoid interference.

==Migration Policy For New Projects==

The information in this chapter is only a suggestion which devices to use while plan new DECT projects. No mixing of old and new handsets or base stations is possible in the same project.

===Handsets===

{|border="2" cellspacing="4" cellpadding="3" rules="all" style="margin:1em 1em 1em 0; border:solid 1px #AAAAAA; border-collapse:collapse;empty-cells:show;"
|+ DECT Handset Features Matrix
! DECT Handset !! [http://en.wikipedia.org/wiki/IP_Code IP Code]/[http://de.wikipedia.org/wiki/Schutzart Schutzart] !! Headset Connector !! Bluetooth !! Color Display !! Suggested Replacement
|-
| innovaphone IP52 || - || - || - || - || innovaphone IP61, IP63
|-
| innovaphone IP54 || IP54 Dust protected, Splashing water protected || YES || - || - || innovaphone IP63
|-
| innovaphone IP64 || IP64 Dust tight, Splashing water protected || YES || - || - || Ascom d81 Ex
|-
| innovaphone IP55 || - || YES || - || YES || innovaphone IP61, IP63
|-
| innovaphone IP56 || - || - || YES || YES || innovaphone IP63
|-
| innovaphone IP61 || IP40 Object size >1 mm protected || YES || - || - ||
|-
| innovaphone IP63 || IP44 Object size >1 mm protected, Splashing water protected || YES || YES || YES ||
|-
|Ascom d81 (1) || IP65 Dust tight, Water jets protected || YES || YES || YES ||
|-
|Ascom d81 Ex (1) || IP65 Dust tight, Water jets protected || YES || YES || YES ||
|}

Remark (1) - see below

====d81====
When operated within an IP1202 or IP1202e based environment, telephony features of d81 and d81ex are equal to the ones of the IP63.

Ascom-special telephony features as mentioned in the Ascom-d81-family-datasheet are not applicable in this use case.

Features such as man-down-alarm can be realized by upgrading the phone with a special Ascom license, documented [[Reference:d81 Protector|here]].

===Base Stations and Repeaters===

The IP1200 Base Stations and all kinds of DECT Repeaters for IP1200 are replaced by IP1202, cause no repeaters are available for the IP1202 based IP-DECT solution.

==DECT System Feature Comparison==
This chapter describes the differences in the feature sets between old and new DECT systems.

{|border="2" cellspacing="4" cellpadding="3" rules="all" style="margin:1em 1em 1em 0; border:solid 1px #AAAAAA; border-collapse:collapse;empty-cells:show;"
|+ DECT Handset Features Matrix
! Feature !! IP1200 based DECT system !! IP1202 based DECT system !! Description
|-
| Registration on 3rd Party IP PBX || YES || NO || IP1202 can only register on innovaphone PBX
|-
| Messaging || [[Howto:Legacy_Method_to_do_DECT_messaging_with_IP1500%2C_IP1200_and_IP600|YES]] || NO ||
|-
| Repeater || YES || NO ||
|-
| External Antennas || YES (on repeater) || YES || with IP1202e
|-
| Non-EU DECT Frequencies || YES || NO || Required for North America, Brazil
|-
| Number of Speech Channels per Radio || 10 || 8 ||
|-
| Max. Number of Radios || 255 || 1000000 || with multiple Mobility Masters for IP1202
|-
| Max. Number of Subscribed Handsets || 1500 || 1000000 || with multiple Mobility Masters for IP1202
|-
| Sync Master Redundancy || NO || YES ||
|-
| Distributed PBX Support with Roaming || NO || YES || In a Master Slave PBX scenario it is possible for DECT Handsets to roam between sites
|-
| Automatic DECT Sync Configuration ||NO || YES || Compared to IP1200 DECT sync, IP1202 is more reliable and stable
|-
| GAP Compatibility || YES || YES || Although both systems are GAP compliant, innovaphone does only support innovaphone handsets used either with IP1200 or IP1202
|-
| CAP Compatibility || NO || YES || IP61/IP63 handsets will always do "external handover" as per CAP (DECT external handover CAP-N.1) between IP1202. GAP-only-compliant handsets will thus not work
|-
| DECT Encryption || NO || YES || DECT Voice Traffic is encrypted between IP1202 and IP61/IP63
|-
| Run innovaphone PBX || YES || NO || On new IP1202 you could not run as innovaphone Master or Slave PBX.
|-
| DECT Security || NO || YES, step B is in preparation || Step B is expected to be published during Q2 2012, see also [http://www.dect.org DECT Forum]
|}

== Usage in non-EU countries ==
The IP1202, IP1202e, IP61 and IP63 can technically be operated in most countries of the world, as the hardware supports all relevant DECT frequencies (software configurable). However, the devices are approved in EU/EFTA states only! Use in other countries will probably be illegal thus.

== Test-SARI ==

DECT Systems are using a worldwide unique system identification (SARI) to be separated from each other.

For test and training purposes, innovaphone offers the following SARI:

31100422072149

This SARI is intended for use in test/training systems only!

'''Usage within productive systems is prohibited and not recommended.'''

If the SARI is changed, all handsets have to be subscribed again.

DECT systems which are near to each other and are using the same test-SARI, may disturb each other.

==DECT Service Codes==

===IP61===
*#34# - Displays the Device Info
*#06# - Displays the IPEI/IPDI

===IP63===
*#34# - Displays the Device Info
*#06# - Displays the IPEI/IPDI
*#77# - Site Survey Tool

==Admin Menu==

The handset has a hidden menu for system administrators. The Admin menu contains:
*Software and hardware information, IPEI/IPDI, and User ID
*DECT link and system information
*Site survey tool
*Fault logging
*Enhanced system menu with ability to alter protection
*Factory reset option

To activate the Admin Menu, enter the Call time screen via "Menu->Call list->Call time" and press <code>> * < < * <</code> .

==Known Problems==
=== Blind Transfer ===
Internal ring tone after external call is blind-transferred to C, which does not save external
number in call list (per IPBS design)
=== Firmware Compatibility ===
Newer IP1202 hardware (such with product code ''IPBS2-M3A '', ''IPBS2-M4A '' or ''IPBS2-M5A'' on the back, introduced 2Q2015) need at least firmware V11r1 SR3 or V10 SR22. Older versions are not supported!

===Remarks===
For a succesfull registration to the PBX, it's mandatory that an entry with the user's ''Name'' as ''Hardware Id'' value exists in the ''Devices'' section of the PBX user.

Reference:IP1202/IP1203 DECT System

2015-12-10T11:20:33Z

Nfinzel: /* Site Survey Kit */

This article describes the new IP1202 DECT system, differences to the IP1200, the migration policy and provides further helpful information.

==Applies To==
This information applies to:

*IP1202
*IP1202e
*IP61
*IP63

It touches:

*IP1200
*IP52
*IP54
*IP55
*IP56
*IP64

==Product Availability==

===IP-DECT base stations===

The '''IP1202''' (50-01202-001) is ready for order since April 2012.

The '''IP1202e''' (50-01202-003) with two external antenna connectors and two included dipole omni directional antennas will be ready for order in Q4/2012.

The '''IP1200''' can be ordered until supplies run out.

The '''defective IP1200''' devices can be repaired via RMA process until 05/2014.

===IP-DECT Repeater and Antennas===

The IP-DECT Repeater '''for IP1200''' and External Antennas can be ordered until 05/2014.

'''IP1202e''' includes two dipole omni directional antennas. Directional antennas have to be ordered separately depending on the use case. Following models will be available for order soon:
* DualDirectionalAntenna (50-01202-004)
* DirectionalSingleAntenna (50-01202-005)
* OmniDirectionalSingleAntenna (50-01202-006)

===DECT Handsets and Accessories===

The DECT handsets '''IP61''' (50-00061-001) and '''IP63''' (50-00063-001) are ready for order since April 2012.

The DECT handsets '''IP52, IP54, IP64, IP55, IP56''' can be ordered until 05/2014 ([http://www.innovaphone.com/en/press/newsletter/news-2014-05.html not available anymore]).

For the new DECT handsets IP61 and IP63 following chargers are available:
* simple charger (50-00060-002)
* programming charger (50-00060-003)(DC4-AAAB/3B) for administration purposes (via WinPDM)
Please be aware of the fact that chargers have to be ordered separately and are not part of the handset!

==Compatibility Statements==

===No Base Station and No Handset Compatibility===
The IP1202-based IP-DECT solution is '''not compatible''' to IP1200 based IP-DECT solution.

The ''old'' DECT handset IP50, IP52, IP54, IP55, IP56 will '''not operate''' on ''new'' IP1202-based IP-DECT system, since not only GAP compliance is required, but also CAP compliance (DECT external handover CAP-N.1).

The DECT handset '''must support GAP and CAP''' for operation on IP1202 based DECT system.

The ''new'' DECT handsets IP61 and IP63 will '''not operate''' on ''old'' IP1200 based IP-DECT system.

The ''new'' DECT base stations IP1202 and IP1202e '''can not be used''' to extend an existing ''old'' IP1200 based IP-DECT system.

=> This means '''NO HANDOVER''' between different systems (move with active call on a specific handset from an IP1200-system to an IP1202-based-system or vice versa)

=> This means '''NO ROAMING''' between different systems (usage of a specific handset in a non-compatible IP-DECT system - see above)

=== Mixed Ascom/innovaphone Environments ===
It is generally not supported to mix Ascom and innovaphone DECT products in a single installation, e.g.

* Combination of IP1202/IP1202e and Ascom IPBS2 base stations is neither allowed nor supported
* Usage of IP61/IP63 with Ascom IPBS2 based networks is not supported
* Usage of non-innovaphone handsets in IP1202 based networks is not supported
* Usage of IP61/IP63 with Ascom Alarm/Messaging Server (ex:UNITE) is not supported

The one and only exception to this is use of the Ascom d81 which may be operated in an IP1202 environment.

===No Multicell License Required===

The Multicell License is obsolete for IP1202-based IP-DECT systems.

For IP1202-based IP-DECT systems a SARI (Secondary Access Right Identity for DECT) certificate is required. The SARI activates an IP-DECT Master based on IP1202. One single SARI certificate is required for a single IP-DECT system, regardless how many base stations are used. Also for IP-DECT systems with one single base station a SARI certificate is required. The SARI certificate is not an innovaphone license and only required to make sure the DECT Radio Fixed Part Identity used in the DECT system is worldwide unique one.

A Multicell License can not be converted to a SARI certificate (and there is also no need to do so).

===Repeater and External Antennas===

There are '''no DECT repeaters available with IP1202''' based IP-DECT solution. Only IP1202-based base stations must be used.

The DECT repeaters for IP1200 are '''not compatible''' to IP1202/IP1202e.

The '''IP1202''' has no possibility to connect external antennas.

In case external antennas are required, the '''IP1202e''' has to be used. The IP1202e has '''no internal''' antennas.

===Certifications and Test Reports===
The innovaphone PBX was tested and certified by Ascom Wireless Solutions with Ascom IPBS based IP-DECT System, on which IP1202 is based (but is not the same product). A [[Media:Innovaphone PBX and Ascom IP-DECT certified by Ascom.pdf|Certificate]] and a [[Media:Innovaphone and ascom DECT Report.pdf|Test Report]] of this certification are available for download.

===Bluetooth Headset Support for IP63===

The IP63 DECT handset supports handsfree and headset profiles for Bluetooth.

Following headsets are tested by the manufacturer:

*3M Peltor WS XP
*Jabra EVOLVE 65
*Jabra MOTION
*Jabra STEALTH
*Jabra SUPREME
*Plantronics BlackBeat GO 2
*Plantronics Blackwire 710
*Plantronics M70
*Plantronics M90
*Plantronics ML20
*Plantronics Voyager Edge
*Plantronics Voyager Legend

==Training and Deployment==

===DECT Training Kit===

To be able to attempt to the optional DECT Training Topic in the Advanced Training a DECT Training Kit must be ordered.

The DECT Training Kit contains:
*IP1202 x 2
*IP61
*IP63
*Charger for IP61/IP62/IP63
*USB-Programming Charger for IP61/IP63

This kit is referred to as ''Trainingspaket 2 (DECT)'' or ''Training Pack 2 (DECT)'' in the price list. Pleas note that this kit needs to present ''in addition'' to the regular training kit.

===Parallel usage of IP1200 and IP1202 IP-DECT systems===

The operation is only possible as two independent systems. No handover or roaming between the systems is possible. An IP1202-based system can and should synchronize the TDM clock with IP1200 based system to avoid interference.

==Migration Policy For New Projects==

The information in this chapter is only a suggestion which devices to use while plan new DECT projects. No mixing of old and new handsets or base stations is possible in the same project.

===Handsets===

{|border="2" cellspacing="4" cellpadding="3" rules="all" style="margin:1em 1em 1em 0; border:solid 1px #AAAAAA; border-collapse:collapse;empty-cells:show;"
|+ DECT Handset Features Matrix
! DECT Handset !! [http://en.wikipedia.org/wiki/IP_Code IP Code]/[http://de.wikipedia.org/wiki/Schutzart Schutzart] !! Headset Connector !! Bluetooth !! Color Display !! Suggested Replacement
|-
| innovaphone IP52 || - || - || - || - || innovaphone IP61, IP63
|-
| innovaphone IP54 || IP54 Dust protected, Splashing water protected || YES || - || - || innovaphone IP63
|-
| innovaphone IP64 || IP64 Dust tight, Splashing water protected || YES || - || - || Ascom d81 Ex
|-
| innovaphone IP55 || - || YES || - || YES || innovaphone IP61, IP63
|-
| innovaphone IP56 || - || - || YES || YES || innovaphone IP63
|-
| innovaphone IP61 || IP40 Object size >1 mm protected || YES || - || - ||
|-
| innovaphone IP63 || IP44 Object size >1 mm protected, Splashing water protected || YES || YES || YES ||
|-
|Ascom d81 (1) || IP65 Dust tight, Water jets protected || YES || YES || YES ||
|-
|Ascom d81 Ex (1) || IP65 Dust tight, Water jets protected || YES || YES || YES ||
|}

Remark (1) - see below

====d81====
When operated within an IP1202 or IP1202e based environment, telephony features of d81 and d81ex are equal to the ones of the IP63.

Ascom-special telephony features as mentioned in the Ascom-d81-family-datasheet are not applicable in this use case.

Features such as man-down-alarm can be realized by upgrading the phone with a special Ascom license, documented [[Reference:d81 Protector|here]].

===Base Stations and Repeaters===

The IP1200 Base Stations and all kinds of DECT Repeaters for IP1200 are replaced by IP1202, cause no repeaters are available for the IP1202 based IP-DECT solution.

==DECT System Feature Comparison==
This chapter describes the differences in the feature sets between old and new DECT systems.

{|border="2" cellspacing="4" cellpadding="3" rules="all" style="margin:1em 1em 1em 0; border:solid 1px #AAAAAA; border-collapse:collapse;empty-cells:show;"
|+ DECT Handset Features Matrix
! Feature !! IP1200 based DECT system !! IP1202 based DECT system !! Description
|-
| Registration on 3rd Party IP PBX || YES || NO || IP1202 can only register on innovaphone PBX
|-
| Messaging || [[Howto:Legacy_Method_to_do_DECT_messaging_with_IP1500%2C_IP1200_and_IP600|YES]] || NO ||
|-
| Repeater || YES || NO ||
|-
| External Antennas || YES (on repeater) || YES || with IP1202e
|-
| Non-EU DECT Frequencies || YES || NO || Required for North America, Brazil
|-
| Number of Speech Channels per Radio || 10 || 8 ||
|-
| Max. Number of Radios || 255 || 1000000 || with multiple Mobility Masters for IP1202
|-
| Max. Number of Subscribed Handsets || 1500 || 1000000 || with multiple Mobility Masters for IP1202
|-
| Sync Master Redundancy || NO || YES ||
|-
| Distributed PBX Support with Roaming || NO || YES || In a Master Slave PBX scenario it is possible for DECT Handsets to roam between sites
|-
| Automatic DECT Sync Configuration ||NO || YES || Compared to IP1200 DECT sync, IP1202 is more reliable and stable
|-
| GAP Compatibility || YES || YES || Although both systems are GAP compliant, innovaphone does only support innovaphone handsets used either with IP1200 or IP1202
|-
| CAP Compatibility || NO || YES || IP61/IP63 handsets will always do "external handover" as per CAP (DECT external handover CAP-N.1) between IP1202. GAP-only-compliant handsets will thus not work
|-
| DECT Encryption || NO || YES || DECT Voice Traffic is encrypted between IP1202 and IP61/IP63
|-
| Run innovaphone PBX || YES || NO || On new IP1202 you could not run as innovaphone Master or Slave PBX.
|-
| DECT Security || NO || YES, step B is in preparation || Step B is expected to be published during Q2 2012, see also [http://www.dect.org DECT Forum]
|}

== Usage in non-EU countries ==
The IP1202, IP1202e, IP61 and IP63 can technically be operated in most countries of the world, as the hardware supports all relevant DECT frequencies (software configurable). However, the devices are approved in EU/EFTA states only! Use in other countries will probably be illegal thus.

== Test-SARI ==

DECT Systems are using a worldwide unique system identification (SARI) to be separated from each other.

For test and training purposes, innovaphone offers the following SARI:

31100422072149

This SARI is intended for use in test/training systems only!

'''Usage within productive systems is prohibited and not recommended.'''

If the SARI is changed, all handsets have to be subscribed again.

DECT systems which are near to each other and are using the same test-SARI, may disturb each other.

==DECT Service Codes==

===IP61===
*#34# - Displays the Device Info
*#06# - Displays the IPEI/IPDI

===IP63===
*#34# - Displays the Device Info
*#06# - Displays the IPEI/IPDI
*#77# - Site Survey Tool

==Admin Menu==

The handset has a hidden menu for system administrators. The Admin menu contains:
*Software and hardware information, IPEI/IPDI, and User ID
*DECT link and system information
*Site survey tool
*Fault logging
*Enhanced system menu with ability to alter protection
*Factory reset option

To activate the Admin Menu, enter the Call time screen via "Menu->Call list->Call time" and press <code>> * < < * <</code> .

==Known Problems==
=== Blind Transfer ===
Internal ring tone after external call is blind-transferred to C, which does not save external
number in call list (per IPBS design)
=== Firmware Compatibility ===
Newer IP1202 hardware (such with product code ''IPBS2-M3A '', ''IPBS2-M4A '' or ''IPBS2-M5A'' on the back, introduced 2Q2015) need at least firmware V11r1 SR3 or V10 SR22. Older versions are not supported!

===Remarks===
For a succesfull registration to the PBX, it's mandatory that an entry with the user's ''Name'' as ''Hardware Id'' value exists in the ''Devices'' section of the PBX user.

Howto:MobiCall - newVoice - 3rd Party Product

2015-10-15T15:46:21Z

Nfinzel: /* Summary */

[[Image:newvoice-logo.gif|||right]]

==Product Name==

[http://www.mobilisierung.com/en/about-mobicall MobiCall]

==Certification Status==

{{Template:Compat_Status_"engineered_prod."|certificate=MobiCall_-_newVoice_-_3rd_Party_Product_-_product-cert.pdf}}

Testing of this product has been finalized April 16th, 2014.

==Category==


{{Category:3rdParty Alarm Server}}
[[Category:Engineered product|{{PAGENAME}}]]
[[Category:3rdParty Alarm Server|{{PAGENAME}}]]

==Functions==


The reliable and professional alarm and event management system for converging solutions in the areas of security, telecommunications and IT.

For your individual security needs:

*Firealarm, mobilization of evacuation assistants, evacuation
*Intrusion, technical and IT alarms
*Emergency calls, bomb threats and voice recording
*Personal and lone worker protection
*Crisis and disaster managemen
*PNA (Personal Alarm system)

MobiCall is certified with innovaphone platform via SIP and SOAP interface.

The following features are supported:

* Display text and on the innovaphone IP-Phones
* Call interruption and call intrusion
* Loudspeaker broadcast
* Confirmation possibilities for incoming messages
* Call recording
* Textmessaging
* PBX interface monitoring
* Localisation
* Technical alarm indicating radio connection loss or Handset out of service

[[Media:NV innovaphone Functionalities EN.pdf|Flyer - Integration of innovaphone communication solutions]]

[[Media:NV_PNA_EN.pdf|Flyer - PNA Personal Alarm System]]

==Version==
* innovaphone PBX and IP phones v10.00 SR8
* newVoice MobiCall NV 7_8_0_20140327, WEB v7.7.5-20140403, Announcement-Package AddOn 04.04.2014

==Vendor==


[[Image:newvoice-logo.gif]]

[http://www.mobilisierung.com/en/ New Voice International AG]

New Voice is a worldwide operating systems integrator and offers solutions in the area of emergency, security, business and process communication as well as IT and automation technology.
<br> Established in 1991, New Voice has implemented more than 4000 systems in all markets worldwide in close cooperation with important telecommunications enterprises, leading manufacturers, systems integrators and security software providers.
<br> The goal is to use real time communication as an efficient source of information for a companyand at the same time toincreasethe level of security and protection ofindividuals
and property.

==Description==

MobiCall is an unique and innovative multi-application information server for automation and productivity control, ready to be integrated into every strategic business process or business critical communications system.
<br> The internationally established solution is especially well suited to be used in case of incidents and critical situations requiring quick intervention of the responsible parties: fire, intrusion, emergency calls, nurse calls, crisis management (conference calls, voice recording), personal protection and IT failures (IT alarms). In addition to many other functions, MobiCall solutions are designed to monitor lone workers and offer support in the case of an evacuation.

<br> The unique, reliable and modular core of the application guarantees the security of men and equipment.
* Data storage in emergency situations is essential to avoid crisis situations
* Regular flow of information in everyday life enhances the efficiency of all participants
* The efficiency analysis of an incident ensures better preparedness for the future

The solutions have to be flexible and easily extended. For the highest possible availability, MobiCall systems and their additional components may be installed and used in a redundant setup within a network. Constant supervision of voice and data connections and data back ups are further essential components of MobiCall and complete the solution.

== Interfaces ==

* Contact interfaces for IP WAGO-I/O system
* Serial connections over ESPA 4.4.4 and ESPA+
* GenericPrinter Protocol
* IP integration over Modbus, BACnet and KNX
* ESPAX
* OPC
* SNMP traps
* XML
* e-mail ( e.g. Nagios)
* HL7
* etc.

==Competitive Analysis==

Alarm and event management are our core business. We support a wide range of systems and integrations. Over 40 employees around the world guarantee an unrivalled service and flexibility. We only uses components that meet our high quality standards and have undergone comprehensive testing by our experts. The extremely functional and high-performance New Voice Application Generator and New Voice Designer are the fundament of the applications. When developing the user interface (system, Web, telephone, communication process management) for individual services, we pay great attention to user-friendliness, functionalism and portability between different operating systems.

Return on investment is protected, since the MobiCall platform can be easily expanded at any time upon the customer's request by adding modules.

==Summary==

* Test report of innovaphone PBX and New Voice MobiCall according the test plan created by New Voice. For detailed information contact newVoice by email support@newvoice.ch / phone +41 58 750 11 11.
* The test were successful and all required tests were passed. As a result newVoice MobiCall qualifies as an ''{{Category:3rdParty_Alarm_Server}}'' [[Recprodredirector#Alarm_server_Products | Engineered Product]]

* [[Media:Innovaphone_Zertifikat_08.05.14.pdf|Technology Partner Certificate issued by NewVoice on 08.05.2014]]

==Pricing==

Contact us by email support@newvoice.ch or phone +41 58 750 11 10

==Contact==


{|

| colspan=99 | New Voice International AG
|-
| colspan=99 | Benjamin Lieber
|-
| colspan=99 | St. Gallerstrasse 8
|-
| colspan=99 | 8853 Lachen
|-
| colspan=99 | Switzerland
|-
| Tel: || +41 58 750 11 10
|-
| Fax: || +41 58 750 11 12
|-
| Mail: || [mailto:lieber@newvoice.de lieber@newvoice.de]
|}

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

Reference10:Concept Voice Recording 2014

2015-09-11T11:54:13Z

Nfinzel: /* Recording with the IP-Phone */

== Introduction ==

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 records are stored in a first step on the Conpact flash or webdav server and processed then form the recorder tool.

Voice recording can be done on a logical or fiscal gateway (BRI, GW, SIP etc.), and therefore all kind of audio traffic can be recorded. Technically spoken a gateway is doing media relay and writes the audio data to the webdav or CF.

The second way to record is recording directly from the innovaphone IP-Phone. In this case the phone itself writes the audio data to the CF or webdav server.

See the “Scenarios” for further details.

The solution requires an innovaphone PBX, the reporting tool 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.

IMPORTANT: All users that should be recorded need the REPORTING! We recommend reporting for all user, see chapter “Requirements” for further details.

== Requirements ==
As webdav server just the innovaphone webdav server (on a GW or IPVA) is supported.

The recorder use HTTP and HTTPS access and not a webdav protocol to access.

===PBX===
You require a PBX version 10 or higher, version 11 is recommended.

===Reporting===

The recording feature requires the innovaphone Reporting. Required Version 10, Build 10043, Version 11 recommended.

At least any user that should be recorded must have the reporting. If user will generate pcap files (do a recording) it is recommended that also those users should have a recording; generally we recommend that all users in the PXN should have the recording on. Here is why: if the recorder found a pcap file (an audio file) he will “ask” the reporting about the involved users. If the reporting has no information (because those users have no reporting) the answer will be a “not found”. Therefore the recorder will try later on more times to found the record in the recording, all that will slow down the entire system.

=== Recorder ===

This document describes Build 10089. Please note that from build 10084 on no more drive mapping is done and 10089 supports https.

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.
The stores voce data is not PCM but a G.711 format in a wave container. PCM require much more disk space and is not used for storing. The audio files can also be encrypted. Encryption would double the required disk space. The recorded conversation is a stereo file where the external caller is on the left channel whiles the internal one in the right channel. It is possible down mix the conversation to mono; this would save about 50%. It is also possible compress the audio data to mp3.

The following table shows the required disk space for one minute of conversation:

[[Image:RecSetup07.png]]

Example: 500GB Hard disk, mp3 compression without encryption -> 1.389 days = 3,8 years of conversation

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 11 innovaphone PBX and a Version 11 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.

Remember that the CF is a relative slow drive, you will note this if you copy a file from the CF to the local HD of your PC. Exact this file copy is one of the task of the recorder, even a critical one (so not a good idea do anything else in between). The result is that the copy of a huge file (a long conversation) or many files will virtually froze the recorder software. In reality the recorder is just hanging around and waits that the file copy is finally done. So a recording on an external webdav server will solve this, but the CF has the nice flair working even if all PC’s are down. Take your choices and live with them.

Require Framework 4.5.

=== Codecs ===
Recording can only be done in G.711 or G.729. Calls with different codes (e.g. G.722) will still be recorded, but no wave files will be converted!

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

In theory it should work on any CPU, the Player was tested under Win7 32BIT, Win7 64Bit and Win8 64Bit.

===License===

The license model is based on user, so for each user to record a license is required.

The current implementation allows a recording of objects of type user or executive. Recordings on other objects will be discarded.

So in short: Per recorded user or executive object you need to have
* one recording license
* one reporting license

In start-up the recorder will read out the number of recording license in the PBX. After that the recorder will read out all users and check if a user is in the recording group (defined in the recorder setup). If a user with that group is found one license is counted down. If there are no more license but user in group detected they will be skipped. The recorder shows how many license where detected in the PBX and how many user are in the recording group. If there are more users than licenses a warning is show.

Remember that just users in the recorder user table are recorded; all other records are automatic deleted! This can be usefully if for example for internal reasons not just the user to record passes through the recording gateway but also others; not being in the group the records will be destroyed. But of course this will cause senseless PBX CPU workload because a recording anyway is done, just the recorder will delete after the files.

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

== Feature list ==

=== General ===

• Using an innovaphone IP-Phone set immediately after call end the recording can be listened using the phone. One feature key stroke and the conversation is reproduced and repeated endless (auto replay). This call can also be transferred or put in a 3 party conference (immediate sharing)

• Online Help and tooltips for application and setup

• Setup password protected, setup files are encrypted

• Recorder in Demo Mode (20 minutes) , Player for free

• Many recorder in one system and unlimited number of players

=== Recorder ===

• Recording of any type of calls direction

• Recording of calls from any device: IP-Phones (innovaphone and 3rt Party), analogue phones, GSM (mobility), IP-DECT

• Recording of calls from/to legacy PBX (smooth migration)

• Recording can be done in a logical gateway or direct from a innovaphone phone set

• Recording of encrypted calls

• Standard und thread call recording. If thread call recording is on after a settable time period (for example 5 minutes) a call will be automatically deleted. If the user calls inside the time period a code the last call will be saved. This marking to keep the recorded call can be done from any type of phone. If the phone is a innovaphone IP Phone the marking can be done also during conversation

• Storage of all relevant data including the time to answer for each call

• Detail protocol of each call, documentation of the entire call flow, not just the recording period but even previous and following one. Detail report on all call situations, transfer, call forwarding, pick-up, group call, conference etc. Also calls in waiting queues or announcements are reported with second accuracy

• Encrypted protocol data

• Display number of channels in recording with start timestamp

• Error and Event log files

• Email alert in case of master alarm

• Automatic backup (copy to mass storage archive)

• Automatic delete of records older than 2-99 month (not on archives)

• Recordings are saved as wave files, can be reproduced with any player

• Wave data integrity supervision

• File name contains primary data (Timestamp, Caller and called, direction, time to answer, UID)

• Counter of recorded conversations

• Data Link to player, remote control of the recorder from player

• Interface to external applications, via TCP or URL, recorder provides data for later retrieving. Player can be controlled sending commands to the recorder (3rd party)

• Mark record during a conversation on the IP-Phone (build 1077)

• Https from Build 10087 on

• Salve sites from Build 10089 on

=== Player ===

• Integrity of the recorded wave files are recognized and displayed

• Agent note, a Player displays automatically agent notes and can add text notes to each call

• Integration with iQM server, display of missed calls, possibility to recall immediately

• Naming of Players

• Month and Day filter

• Filter for internal and external number with wildcards

• Filter for incoming and outgoing calls

• View of oldest or newest call on top

• SOS mode can be switched on/off with just one click. If on all unnecessary key are hide, the newest calls are displayed on top of the call list and filters are switched off

• Selection of calls, one single call, more single selected calls, from to, all

• Online search and display, can be switched off

• Copy, move and delete of calls

• Move and delete operations are logged in centralized manipulation log

• Permissions

• Multiple selected calls can are transferred automatically in a playlist and can be reproduced

• Display record size

• Display number of records in playlist and actual play

• Jump forward and backward in playlist

• Jump to next/previous title in search result list if playlist contains just one record

• Marc record in playlist, select actual record and clear all others

• Play one title after the other in playlist

• Play a beep if record change in playlist (loop playlist)

• Repeat play (loop record), up to 4 positions, stored automatically

• Repeat play of all stored memory positions

• Display internal and external number with name resolution

• Display timestamp, time to answer an call ID

• Display System and Player status

• Display if local remote control interface is on

• Display of play was forced be recorder remote control

• Keys for Stop, Play, Fast Forwarding, Rewind, Pause and Eject

• Display duration record

• Display elapsed time or count down, switchable

• Original time elapsing display

• Progress bar adjustable, direct jump to selected position, drag and drop

• Start and Stop position can be marked an played in loop (selection loop)

• Volume control with audio meter and peek indication

• Delta level Indication (L-R and R-L meter)

• Overflow level audio meter

• Enhanced sensitivity for audio meter

• Attenuation left and right cannel adjustable

• Audio setup can be stored and recalled

• Audio level at maximum

• Levels are stored and set on restart

• Level meter with peek indicator for left and right cannel

• Mute

• Large additional display with call details

• Automatic decryption if files are copied

• Player can be limited to display just calls of one extension

• Communication with recorder, display of link status, last master alarm and cannels in recording

• Reset recorder from player

• Search an play on backup directories

• Operate as Media player, reproduction of audio format wav, mp3, wmp and video format avi, wmv, mp4 and mpg

• 1rst and 3rd party remote control

• Document security, manipulation is detected and displayed

• Browse last played records (build 1071)

• Browse marked records on this player (build 1071)

• Browse marked records in a system wide available directory (build 1071)

• Mark records on player and for system wide access (build 1071)

• Copy records marked in a player to the system wide available directory (build 1071)

• Write a central log for all player listening’s (build 1071)

• Work over hhtp connections (build 1074)

• Limit view to a list of extensions (build 1077)

== Scenarios ==

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 on a central point ===

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 or G729 on a logical gateway as endpoint. If you want record internal calls in this way calls must always transit a logical gateway (with the media relay flag on).

=== Recording with the IP-Phone ===

Recording can be done also directly from the innovaphone IP-Phone.
If switched on all calls from and to this phone are recorded, there are no recording rules. Calls could be stored in different files, because a new call means also a new file. If for example a phone put on hold a conversations and establish a second call this second call will be stored a an separate file.

Doing voice recording using the IP-Phone or using a Gateway has advantages and disadvantages; it depends on your point of view and the scenario.

Here some issues to remember:

Recording on a gateway is like the old “ISDN Recording”: anything passing that interface is recorded. That has the advantage that any type of endpoint (IP, 3rt party, Dect, analog etc.) will be recorded. The disadvantage is that internal calls are not recorded. Also the CPU load of the PBX will rise while recording with an IP-Phone has nearly no influence.

Recording directly from the Phone has the limitation that just innovaphone IP-Phone are able to doing that. Only innovaphone IP-Phones IP2x2, IP111, IP241 and IP240A with bigger DRAM (http://wiki.innovaphone.com/index.php?title=Howto:Upgrade_IPxxxA_to_support_more_DRAM_Memory) can performing Voice Recording directly.
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).

In the V11r1 IP recording on the phone can just switched on or off in the setup, not from the user. In V11r2 recording can switched on and off by the user (similar to the 3party version).

Note: The recording described here does not require a phone 3 party conference; therefore a 3party conference is possible on the phone while recording is running.

== Recording Modes ==
=== Standard Recording ===

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

Note: A recorder canoperate just in one mode (for example "Standard"). Mixed scenario are possible but require two or more recorders, the setup in this case has to be done very carefully.

=== 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 sub-directory TCR in your PCAP recording directory and copy the xml in, create a VM-Object in the PBX and insert those parameters in the recorder setup (TCR panel). Example: Your PCAp directory is http://172.16.88.98/DRIVE/CF0/REC, therefore the directory create is is http://172.16.88.98/DRIVE/CF0/REC/TCR. 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.

=== Random recording ===
The recorder can work in this mode also as an alternative to the Standard- or Threat call recording. Random recording will record just a sample of calls on normal Agents (User), typically for quality check purposes.

The system allows record just each x call where x can be set in the setup. The system can even record just each y call for an agent. Only “to recording” calls are counted, not calls in general.

Example: “Record in System just each 3. Call”’: the system will store one record and then skip the following 2 one.

Example: “Record for a Gent just each 2. Call”: for each agent one call will be recorded and one not.

Both setups can be set isolated, but combined (3rd in system and 2nd for a agent) the system will first skip 2 calls and then for the specific agent skip each 2nd one.

Calls typically are not foreseeable especially if they are more agent involved and therefore it is for a single agent a “random” recording.

This feature requires build 1071 or higher.

=== Manual/Transparent/Optional recording ===

V11r2 (in the Phone) is required.

If the recording is done using a innovaphone IP Phone there are 3 recording modes possible:

- Manual: the user switch recording on/off using a Feature key

- Transparent: recording is always on

- Optional: recording is on by default but the user can switch it off using a feature key

The manual and optional mode is widely used because the operator can switch on and off recording during a conversation. For example if the customer want to buy the operator starts recording and give the advice that from now on the recording is on (by the way: that can be played also automatically modifying the last call recording xml). Switching off recording is usefully also if for example during a conversation a secret info (like a password) is stated and should not be recorded ad all.

The Recording link (url) to the Webdav or CF is defined in the user setup:

[[Image:RecSetup08.png]]

The mode is selected in the "recording" section:

[[Image:RecSetup09.png]]

Note: The recording described here does NOT require a phone 3 party conference; therefore a 3party conference is possible on the phone while recording is running.

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

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

(*) = Option

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.

== Installation Step 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 course, 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/System_Setup#Gateway_Setup . If you want to do a test with internal phones you have to assure that in call 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 course 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. Start the application and open the setup.

== Installation ==

While the Recorder works “hidden” for the user, the Player has a huge user interface. The Player is typically installed on one or more PC of users. Therefore for the Player more effort to design a foolproof interface was done. The Player description is available, 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 is even encrypt.

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.

=== Date ===

As most application also the recorder requires a correct date and time. But also the PBX Date and time must be correct and the same as the one on the recording PC.

Basically obviously, writing a file all file data should be correct, and also the CDR ticket data should.

So verify that both, PBX and PC have always a correct and synchronized date and time.

== Voice Recorder operation ==

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

[[Image:RecE111B1.png]]

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

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

*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:RecE111B2.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.

The following picture shows two alarms, Reporting (because there where files without CDR records) and Software (because there was a license overflow).

[[Image:RecXX.png]]

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

Basically calls that should not be recorded should not be recorded even on the CF, this is desirable, but not always feasible.

In normal operations the recorder is connected to the PBX with a SOAP link and can so detect when a call is finished and the party involved. If there is a PCAP file and a SOAP connection fine, because in the very first step anything is clear and the recorder can decide to save or to just delete the PCAP file. But there is also the possibility that the recorder starts up later and “found” PCAP files stored in the meantime. In this case there could be or even not any SOAP information, if the call terminated before the recorder starts there will no SOAP info. Therefore if PCAP files are detected without any SOAP indication the recorder ask the reporting if there is any record to that PCAP. If yes the processing will follow the normal way, stored or just deleted. But if the reporting has no data there are more possible reasons. CDR data or the reporting could be “late”, so maybe in a few seconds data are in and processed. Or the reporting was just temperately busy or offline, a good idea is wait and try later again. Exactly that the recorder is doing, from build 1070 on the number of trial can be set in a range from 5 to 9999, default value is 5. On earlier build this value was set fix to 1444. Arrived to zero the call is deleted. Deleting recorded calls not knowing about the party involved is critical and therefore the recorder is so carefully.

The real problem is if in a system there are extensions creating PCAP files, but they did not produce CDR tickets / have no CDR license. In this case after a start-up each stored call will produce a PCAP file, the reporting query will fail and the recorder will try later again. To avoid large quantity of PCAP files and slow call processing switch on the reporting feature on each extension creating PCAP files. Or avoid that extension without a reporting creates PCAP files.

Receiving an answer form the reporting the recorder understand immediately the involved parties and can delete the file if the caller was not an Agent or store it.

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

Eventual notes are stored in a file named “2013_06_24_1638_39_o_0800102_7_75c1f48e909d31188fc00903306225f.txt”.

This file is AES encrypt, see relative chapter. If this file is copied with the innovaphone Player it will be automatically decrypt and becomes a standard XML file.

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.

==Encryption==

The setup files for player and recorder are encrypted, as fix key is used an innovaphone specific secret key. The notes are not encrypted while the reporting and security file (the .xml) is encrypted.

So the reporting and security files are encrypted (those ending with “.xml”) using again as default the innovaphone system key. This default encryption key can be replaced with a customer specific key. In the in the setup of the recorder can be defined a customer key. The only reason to define a customer key is to avoid that other customer can decrypt the files, a remote and strange, but thinkable situation.

If this is done in the Recorder also in all Players must be set this customer decrypt key. Be careful in handling that key, because if you forget the key you will lose all encrypted information. The Player can handle contemporaneously the default key and the specific key. There is no update procedure foreseen if you change the key.

Example:

After 3 month of default operation you decide to insert a customer specific encryption key, for example “MySuperSecret007Key”.

You modify also the Player and insert in the setup this new key. Now you will observe that all data, the one of the first 3 month and the following one, will be decrypt automatically correct; the user will see no difference.

After other 5 Month you decide to return to the default key (leaving blank the key field again in recorder and player). Anything is going well, all records are decrypted correctly.

After other 2 Month you decide to enter a key named “MyBrandNewKey”, doing setup of recorder and player. You will observe now that the data of the month period 0 to 3 , 5 to 7 and after Month 7 will be decrypt while Month 3 to 5 (the one with the old key) will be displayed without CDR data and status “unknown”.

Therefore think well about your key, basically once selected it should remain. If you have the list of all Keys you can of cause change it on the fly in a player and decode the records in the period.

=== Audio encryption ===
The security system is based on AES encrypted xml data file. That file contains the CDR data but even the security parameter of the audio file. Therefore if an audio file is manipulated (changed in any way) that will be detected and show in the player (the “manipul” red label is on while off and the green “original” on if the audio file is the original one).

That means that the audio file itself is not encrypted. A fact and feature most customers want (reproducing the file even with other media player). At the end the access to the files should be forbidden to not authorize people.

But there are also customer that have another view and are worried about for example that such an audio file once copied is no more controllable. Or they simply do not thrust that the security features described works fine.

Therefore also the audio file itself can be AES encrypted if that option is switched on in the recorder. The player will detect automatically that an audio file is encrypted and reproduced it anyway.
Here how a player shows a detected Audio encryption:

[[Image:Sec04.png]]

Of cause an encrypted audio file can be reproduced just with the innovaphone player, no other media player will work.

Please note that any innovaphone player can do the decryption, so if you want to assure that just “your” player can reproduce you have to define a customer decrypt key in the recorder (and player).

The recorder shows audio encryption in his extended view:

[[Image:Sec05.png]]

Audio encryption has also disadvantages, recorder and player has more workload.

But the worst thing is the required disk space; in fact size of the audio files will double if encrypted!

==Audio compression==

=== MP3 ===
As default the files are saved in the wave format. More precisely in G711 because wave is a container format and pure PCM would require near the double disk size than G711.

As an option a mp3 compression can be activated. The required disk size is about 75% less, so one minute in wave requires about 1Mb while the same data in mp3 will require 250kb.

If you wonder why the savings are not much higher consider that even the wave format itself is jet compressed as explained.

All other functions like encryption (an encrypted file size is again doubled, so one minute of mp3 audio encrypted requires about 500kb) or reproducing are the same, the user has nothing to do and the player works always in the same mode.

There is just one situation where an action is required: if the recorder works for a certain period with wave and then with mp3 (or vice versa) in the directory of that month there will be mixed files (wave and mp3). The player detect this and shows automatically an additional key where the user must switch between those two formats: if a directory has just one type of files no action is required and the button is hided.

===MP3 Stereo to Stereo conversion===

If the MP3 option is on, files could also be converted form stereo to mono. The file size savings will be nearly 50%, so one minute conversation in mono MP3 requires about 130kB.

Note that conversion from wav to mp3 causes quality lost and stereo to mono even. Once converted, there is no possibility to return to the original format in terms of quality or format. So a bad mono mp3 quality cannot be recovered and even the stereo separation of the cannels cannot be done once converted to mono.

===MP3 just internal channel===

An interesting option in using MP3 is to record just one channel, the left (default) or the right one. The result is a mono file (130kB/min) where just one party is recorded.

If a GW point to an external trunk the internal user is always talking on the left channel. Therefore with this option on just the voice of the internal user is recorded, and doing that in many countries is simply allowed without any restrictions (basically I can record myself).

If recording is done on the phone the channel assignment is vice-versa, the internal caller (the phone) is recorded always in the right channel. Therefore in the setup of the recorder can be selected which cannel should be recorded. That means also that no mixed scenarios (GW and Phone recording) are supported for that feature.

[[Image:RecSetup01.png]]

== Redundancy ==

The recorder is able to handle redundancy scenarios with active and standby devices.
The recorder has to handle 3 sources in different scenarios, the PBX itself, the reporting and the CF or webdav server. Those devices can be all together in one single device (for example in an active IP6010 with reporting and CF and a standby IP6010 with reporting and CF) or on different devices (for example an active and a standby IP800 and two reporting on two different PCs).
Another example is active and standby PBX on Gateways but reporting on a high availability VMware environment, so at the end just one reporting from the recorder point of view.

Therefore the standby can be defined for each of those devices.
If you have no redundancy scenario just leave blank the relative setup values.

=== Active/Standby PBX ===

The failure of the PBX is detected because the SOAP connection will go down. If that happen the recorder will try to establish an alternative link to the standby PBX, if that fails he try again with the primary PBX and so one. That means also that a breakdown of the SOPA connection, for example if you reset the PBX, will require some more seconds until the system is up again (because first the recorder try the standby PBX, this will also fail and after that the main SOAP will be up again).

Note that after a restart the recorder try always the first the main address and then the standby one.

In the panel of the recorder near the PBX status indicator is shown the actual link: if the “ACT” lamp is green than the active PBX is tempted, if gray and the “STB” lamp on the standby link is on.

Please note that the recorder can handle differences in active and standby mode just regarding the IP address. All other parameter must be the same, so for example the path to the reporting must be the same.

=== Active/Standby Reporting ===

If the link to the reporting fails and there is a standby address indicated the recorder try to reach the reporting using the standby IP address for the reporting. If there is just one reporting leave the standby address blank.

As you (hopefully) know the reporting can also be installed on two devices, in that case both PBX (the active and the standby one) will transmit CDR ticket to both reporting applications. The reporting database is replicated and therefore if both devices are on the recorder will find the same informations on each reporting. So in theory if both are on it is not important where the reports are requested. In fact if the active reporting fails the recorder will try a connection to the standby reporting. Now if the active device and relative reporting is on again the recorder could also continue get records from the standby reporting. And he will do that until he is restarted or the standby reporting is down because the reporting will answer. If that is not desired flag the option in the recorder setup (“follow Standby/Active PBX”); doing so the recorder will communicate again with the reporting on the active PBX if the active PBX is up again. So basically the switch is done on link down but also following the SOAP.

=== Active/Standby CF ===

If the PCAP files are buffered on a CF and the PBX goes down also the recorder has to re-map his drive to the standby PBX. In the setup there is a flag in the PCAP section (“follow Standby/Active PBX”), if on the recorder will try to reach the CF of the standby PBX (he takes the IP address of the standby PBX) in the setup.

In scenarios where an external Webdav server is used that flag should not be switched on. The redundancy in that case is demanded to the external devices (for example VMware).

So if you have a “classic” innovaphone redundancy (two IP6010 with reporting and CF) indicate the standby address in the PBX and Reporting panel and switch on the “follow Standby/Active PBX” in the reporting and PCAP panel and anything is fine.

== External Applications ==

The recorder as well the player can be interfaced with external applications like booking or ticketing systems or similar.

The basic idea is that the external application will share common information in his database with the recorder and pilot a player. The user should be able to play a recorder conversation directly from his application interface.

In this chapter the interface is described. If you are not interested is such a feature you can skip this paragraph.

This description is done for the software developer of the external applications. No particular setup for the recorder or player is described, part of other descriptions.

For better understanding the description “hides” all other interfaces.

The “recorder” is a software solution running on a Windows “server” (can also be a simple PC). In the network there will be one or several “players” able to reproducing the recorded conversations.

Under “agent” in this description we understand operators working with the voice recording and using an external application.

It is possible to have a TCP connection between player and recorder but this is not mandatory because the player just access to stored data and read out setup file in the network. The number of player has no limit while the number of player connected to the recorder via TCP is limited to 100. That means that the external application can control up to 100 “agents” trough the recorder. But it is also possible to control a player directly; in this case the remote control has no limit.

Contact us if you have more than 100 agents with voice recording using an external application, we can easily extend this limit.

=== Principle and definition ===

This is the described scenario:

Recorder communicates with Player 1, Player 2 … Player x

The Application server communicates with the Application Client 1, 2, … xx

This description regards the TCP/IP interface in the following picture, the only one to build new from the application point of view.

[[Image:Layout02.png]]

Going on in the description as “Appclient” is intended the User frontend (“Application on terminal x” in the picture).

“AppServer” is called the server of the application (Application Server in the picture), so the server for the ticketing or booking system or whatever.

Keep in mind that just one AppServer can communicate with the Recorder while even each Player can be called even directly from the Appserver or an AppClient. Do not confuse: There are two ways to interface the voice recording system, via TCP and via URL. The smarter and better way is the TCP one. We describe both, read both because in the second section some concepts described in the first one are not repeated.

=== TCP/IP Interfacing ===

This is the preferred and smart way to realize the interface.
All messages and command goes to one single interface as shown in the picture. The Appserver act as a TCP/IP “Master” and will receive from the recorder messages and can send commands to the single Players trough the recorder. So it is a 3rt Party interface, piloting single player using one single IP address. The “play” command for a certain player is send to the recorder (and not to the relative player).

If for example a AppClient wants that the Player starts reproducing a record the command flow will be:

AppClientX press the play key -> AppServer send command to the -> Recorder -> Recorder send a command to -> PlayerX

So the idea is that in the applications is a “Play” and a “Stop” button; if the agent press this button the recording relative to the displayed database record will start to play, pressing stop the play will stop.
Therefore the applications database must contain the record name.

The problem is that the entire information about the record is available just a certain time period after the call end. In most of the cases the application session is terminated or a new one started. Therefore the link is provided in two times.

When voice recording starts, the recorder will send a first record to the AppServer in the following format:

''!FRST!<Extension Number of the Agent>!<UID>!<Agentname>''

<FRST> = indicate that this is the first (of two records)

Extension Number = the Phone number of the Agent

<UID> = a unique ID of the record

<Agentname> = the CN (common name) of the Agent in the PBX

Example:

''!FRST!24!c03a55c2e909d311b6450090331b3e3b!Rossi''

where ''“24”'' is the extension number of the agent, ''“c03a55c2e909d311b6450090331b3e3b”'' is the unique “serial number” of the record and ''“Rossi”'' the name of the agent.

Just the filed ''“!FRST!”'' has a fix length, all the others not; the single field therefore has to be separated searching the “!”.

At this point the applications probably store this information (number, ID and Name) in his database or buffer this info until the Agent has his client ready or similar. Important is that the database record of the application is linked to the record UID.

Basically it is necessary for later data processing that the application server knows the name of the player (in our example “Rossi”). The simplest way to do that is giving the extension in the PBX the right common name (the same name than the application user name). If that is not possible (for example because the application has other items to identify a user) the application has to hold a cross reference table: application user name 1 = recording user name 1 etc. Consider also that not necessarily a record is played only on the player of a certain agent; recording for agent 1 can be required to be played on work station agent 2.

When a call has terminated, the record converted, saved etc. (means, ready to be played) a second record is transmitted from the recording server to the AppServer:

''!LAST!<Extension Number of the Agent>!<UID>!<Track>!<Agentname>''

<Track> = Name of the recorded file, to transmit later to the recorder to play.

Example:

''!LAST!24!93adee5ee909d311b6450090331b3e3b!2013_09_24_1107_39.o.024_1_93adee5ee909d311b6450090331b3e3b.wav!Rossi''

You see that the UID is in again and on the same position; even the extension number and name is repeated. In this way the application can easily search the UID in his database (and the name and/or the number) and when found complete the record entry with the record name (in the example ''2013_09_24_1107_39.o.024_1_93adee5ee909d311b6450090331b3e3b.wav'').
You see the UID is also part of the record name and in theory the original “stand alone” UID in the application database is no longer required. Therefore a overwriting of the UID field in the application database with the record name is possible.

Note: In the actual version a reverse search is not implemented (that the player told the application to display a record). If implemented in the future the search string will be the entire record name and not just the UID, therefore the stand alone UID has no further sense from the voice recording point of view.

From the timing point of view the first message is critical because the UID has to be written until the Agent has opened his application record and that can be even a short time.

The last string is not very time critical because the retrieving of a record and a update can be done in every moment.

The recorder software has a small send buffer (about 25 recordings) where the messages will be buffered if the AppServer is not reachable or the link is down or. If for example the AppServer is switched off and later on again, the recorder will send to the AppServer the FRST and LAST messages buffered during downtime. The Buffer is a Fifo (first in first out) but not an Overflow-Fifo; if full not the oldest but simply all newer messages are lost. The buffering is done just to buffer short time periods, for example to allow a restart of the AppServer PC without losing information (but not for a “offline” operation).

In the application software design should also be considered the possibility that the AppServer receives a First record, is then stopped, and receives the second one after the restart.

That’s all regarding the recording part, now we discuss the remote control of the player.

Remember that a name can be assigned to a player, for external applications that is mandatory. The name can be defined in the player setup; a good idea to simplify the scenario is to give the player the common name of the phone. So in our example we will name the player of the agent “Rossi” just “Rossi”. Not a must of cause, you can call the player of Rossi even “myFirstAgent” or “1234”; but in doing so the external application must store a table where “Rossi” is mapped to “myFirstAgent”. To avoid such complication we suggest unifying the names and assigning to the phone user, Player name and application user in the same one.

To force a certain player to reproduce a certain recording the AppSever has to transmit to the recorder the following command string:

''TRAC!<PN>!<Track>''

<PN>=player name

Example:

''TRAC!Rossi!2013_09_24_1107_39.o.024_1_93adee5ee909d311b6450090331b3e3b.wav''

The Player with the name “Rossi” will start playing the record ''2013_09_24_1107_39.o.024_1_93adee5ee909d311b6450090331b3e3b.wav''.

There are not foreseen any error messages, if for example the player will not find the record or is switched off nothing will be transmitted to the AppServer. In case of record not found on the Player a blank result will indicate the fail. If the recorder start reproducing a record a green “RC” label (for Remote Control) near the play symbol shows that a remote control message and not a manual play key press has started the reproduction.

There are available also other commands:

''STOP'' (Stops the actual play)

''EJEC'' (the actual record is unloaded, the player stops)

''PAUS'' (the actual record is paused)

''PLAY'' (the actual record is played again)

Example:

''EJEC!Rossi''

Will force the player Rossi to stop the reproduction of the track and go in an idle mode.

Generally it is not necessary that the AppServer takes care about the actual Player status or observe command flows. If the Player is for example playing a track and the application server send the command to play another track he will Eject the actual track and play the desired one.

Note also that the player can work minimized in the taskbar and play “invisible”, so the user will see just the application. In the setup of the player can also be defined an automatic popup if a remote play is received and automatic hiding if an eject-command is received. If this is enabled in this way the player is minimized in the taskbar and the user works just with the application screen.

The TCP/IP link between recorder and AppServer is based on the fact that the recorder acts as a slave while the AppServer act as a Server. In the Setup of the recorder the IPadress and the port of the AppServer has to be indicated. The recorder expects on the same port where he is transmitting the response from the AppServer.

The recording server performs a keep alive with an interval settable in seconds. The keep alive message send from the recorder to the AppServer each xx seconds is:

''RecKA''

The message has no further meaning and can be thrown away from the AppServer. If any command is received from the Appserver the keep alive will be skipped and repeated after the, in the recorder setup indicated timespan. Unknown messages form the application server will be throw away from the recorder server.

=== URL Interfacing ===

URL interfacing is available only on a local port (127.0.0.1) and used for interfacing with the reporting (see relative article). The following description is just for internal use.

''<IPLTRAC><PN>''

There are also available the commands

''IPLPLAY''

''IPLSTOP''

''IPLEJECT''

''IPLPAUS''

Example:

''IPLTRAC2013_09_24_1107_39.o.024_1_93adee5ee909d311b6450090331b3e3b.wav''

will force the player to reproduce the indicated record ''2013_09_24_1107_39.o.024_1_93adee5ee909d311b6450090331b3e3b.wav''.

Basically the interface of the player is anyway a TCP/IP interface and no mini Webserver is integrated. But a “Get” from an browser will be detected and decoded, but no answer occurs. That means if you try to launch a command with a browser it will work, but the browser will show you “no page”.

Example:

If you post in your browser “''http://127.0.0.1:9090/IPLPLAY''“, the player will start to play the marked record.

If a port for direct remote control is switched on a “RC on” label is displayed in the player status line.

=== General Note ===

The first UID will be detected form the recording using the SOAP interface in the PBX. Therefore all Agents has to be in the same group that the SOAP user object.

Example: You have a simple user object called “MYSOAP”, put that object in an active group called “Recording” and now put all you Agents in the same group.

Remember that basically recording is done even without the group stuff. So the group is just required to detect the UID in “advanced”. But there is also an additional benefit; the reporting has less stress because the recorder will query the reporting just at the end of the call (knowing via SOAP when the “end” is) while calls without the group are detected as “finished” because the reporting has a valid CDR record, and so the recorder polls each 4 second the reporting on active calls. That means that it is in any case a good idea put the agents in a group, even if no external application is running.

== Recording rules ==

The recording rules describe how the innovaphone PBX and the innovaphone voice recorder works in complex situations.

While basic calls are simple and strait forward in logic, voice recording behavior becomes non clear in complex situations.

What about voice recording if for example a recorded user transfers the call to a “normal” user? Answer: This call will be entirely recorded and booked under the recording user by design; those behaviors are intended under “recording rules”.
From a technical point of view mostly no other solution is possible, form a political point of view any rule could be endless discussed.

Remember that in this chapter “Agent” is just the wording for “user enabled to recording with license” while “user” is a “normal” user, eventually even recording pcap files, but he is not in the recording user group.

In theory senseless recording should not be done. So deleting a record because it should not be stored is a task of the recorder; not recording at all if not necessary is better. That can be achieved avoiding or forcing extensions to the recording gateways or doing recoding directly from the IP-Phone.

The length (or contend) of a record depends; if the recording is done on a GW the entire call will be recorded (if not you will find a note in the rules), from his very first answer to the end. Therefore all the parties involved are even recorded. If recording is done on the phone level just the active call time on that phone will be recorded.

Generally spoken there are not necessary recording rules if the recording is done from the innovaphone IP-Phone: the recording starts when the phone answer the call and ends when the phone hangs up.

So the following table shows the recording rules if recording is done on a GW level.

“External” is the external calling or called party. Of cause if you record even internals calls (forcing all calls in a GW) in some situation the “External” is in reality a internal user, but this will not change the rules. The recorder recognizes the “external” party involved simply because it is the longest number involved.

The recorder stores always even the reporting data and therefore all details are visible in case of doubts. The audio filename anyway if formed just from the internal user number and the external user number even if more numbers are involved in the call (for example in a 3party conference).

Example: External call from number 012345 goes to the Agent number 24, after 3 second he will answer: the result will be a file name like “2014-05-12 14:00_24_i_012345_3_UID”.

Later on in the player you can search “24” or “012345” (or a fraction of it like “0123*” ecc.). In the reporting you can search also all other fields (like other involved extensions) and start the player than from the reporting (see relative function in the innovaphone player).

Note: the following rules works on any type of call transfer (with or without announcement).

“Delete” means that the call will be deleted on the CF. “Call” means that they talk. For example “Agent calls External” indicated the direction and means also that the involved parties talk (or at least produce a pcap file).

Rules:

• External call to Agent = Agent

• External call to User = Deleted

• External call to Agent, User pick-up the call = Agent

• External call to User, Agent pick-up the call = Agent

• External call to broadcast group, Agent answer = Agent

• External call to broadcast group, User answer = Deleted

• External call to User, User hold and transfer to Agent = Agent

• External call to Agent A, Agent A hold and transfer to Agent B = Agent A

• External call to Agent A, Agent B pick up the call = Agent A

• External call to WQ, WQ call XML with DTMF input, XML call WQ, WQ call Agent = Agent (just the external Number is considered, not the DTMF codes and numbers between)

• Agent call External = Agent

• Agent call External, Agent hold and call transfer to User = Agent

• Agent call User, User hold and transfer to External = Deleted

• Agent call External, Agent hold and talk with User but no call transfer = Agent (just external conversation is recorded)

• Agent A call External, Agent A hold and transfer to Agent B = Agent A

• Agent B call External, Agent B hold and transfer to Agent A = Agent B

• User call to Agent, Agent hold and transfer to External = Agent

• User call External, User hold and transfer to Agent = Agent

• User call External = Deleted

• User call External, User hold and talking with Agent but no call transfer = Deleted

• User call Agent, Agent hold and Agent talk with External = Agent (just the external conversation is recorded)

• External call to Agent, Agent has activated a unconditional call forward (CFU) to a User = Deleted

• External Call to Agent, Agent has activated a call forward on busy (CFB) to a User and is busy = Deleted

• External Call to Agent, Agent has activated a call forward on no response (CFNR) to a User, User answer after timeout = Agent

• External call to Agent A, Agent A has activated a unconditional call forward (CFU) to Agent B = Agent B

• External Call to Agent A, Agent A has activated a call forward on busy (CFB) to Agent B and is busy = Agent B

• External Call to Agent A, Agent A has activated a call forward on no response (CFNR) to Agent B, Agent B answer after timeout = Agent A

Note: If Threat call recording is on a call can be marked to store from the calling or called agent. But if both parties are Agent, the called Agent has to dial the code for storing: if the caller dials the code the record will not be saved.

From version 11 on the generated pcap file have a different format. While in former versions the name of a pcap file was a unique single long number form version 11r1 on the ticket as two additional id, one is build form the serial number of the device and the other one if an increasing number. This new format is also generated when recording is done form directly the phone. The recorder can handle both formats automatically, no special setup is required.

We want to focus your attention on the reason of the new format. If for example the recording is done on the phone the phone will generate a new pcap file each time a new call is opened form the PBX point of view.

Example: Phone rings and the user answers, the recording starts with record 1. Then the user put the call on hold and call another extension, this generates record number 2. Then the phone returns to the first call and continuous talking that will be the 3td call. Of cause using the player you will see those 3 calls one after the other (using the user as filter). That this is one situation you recognize looking the reporting details displayed and if you select the 3 calls the player will play one after the other (switch on the loop key) and you listen the entire call in one shoot.

== Known Problems ==

===Open a ticket===

If you have a problem with the recording tool you have to open a ticket as usual. Describe your problem, but send us also the following information:

- Setup of your PBX (with standard password or tell us the password)

- Version of the reporting

- Attach all log and error files and the setup of the recorder. All those files are in the log folder (so zip the entire folder), you find the path and link to the folder in the recorder setup.

- Make some screenshots if possible.

- Open the reporting and do a query where the recorded conversations are in (if possible). Do an export in XML and attached it.

=== No CDR ticket after start-up ===

If a record is not found on the CF and there is no SOAP info about that (for example if you start the recording and there are old terminated calls) the recording checks if the reporting has a related record. If a record is found and it is an Agent involved the record is stored as usual, if no Agent is involved the record will be deleted.

But if there is a recording file found and in the recording there is no related record, the recorder cold simply deletes that record; but this could be fatal. For example the reporting could answer once bad, or the link between the reporting and the PBX is temporary down; in that cases the recording will be lost if simply deleted. Therefore the recorder waits in this situation and asks the reporting again after 2 hours. If even after 2 hours the reporting answer with no record found the file will be deleted (otherwise normally processed and stored or deleted as described before).

Note that the reporting is not aware about the health of the connection between PBX and the Reporting. If the recorder gets no answer from the reporting an alarm occurs and the reporting will not proceed with the storage. But the answer “no record found” is not a clear situation for the software. Therefor this situation has to be avoided and occurs for example if pcaps are recorded, but the users involved have no reporting while the recorder is down and starts up later. So the recorder will “find” pcap files but no reporting information.

During online operation this will not happen, because the SOAP driver will tell the recorder that a specific record has to be deleted, and so the recorder will not check the reporting. This is done even to speed up the recorder because the communication with the reporting is relatively slow. If for example there are many users doing a recording (because a bad setup or simply because a huge PBX) and there are only few users to record a huge amount of files are simply to delete without any further processing. Deleting of files is relatively fast during online operation while in case of startup and then recover historic records it becomes slow, and very slow if there are no CDR tickets. The online deleting of files is just “relatively fast” because the SOAP is very fast but the recorded file has to be closed before deleting. Trying to delete a not closed file will cause an error, if that happen the system after e while will recover, but it is not nice. On top there is no way on a CF to understand if a file is in use or not. Therefore the system will wait 2 seconds before deleting a file.

=== No CDR ticket online ===

There is even an unclear situation in online operation. Imagine that an Agent transmits no CDR information to the reporting (for example because there is no reporting license assigned to that user) or, because of a bad setup in the PBX, the ticket will not arrive to the reporting. A call of an Agent is terminated, the SOAP driver informs the upper layer of the software about that and now the recording ask the reporting about the CDR details. Note that the reporting is not down; the recorder can reach the reporting and get also answers (otherwise the REP alarm would be on). If after a detected call end of an Agent signaled by SOAP and a timeout of 5 seconds no CDR is in the reporting a garbage select routine is activated in the recorder software; this routine ask a second time after other 5 seconds the reporting. If even now the response is “no record found” the reporting waits for this call 2 hours. After 2 hours a third time the reporting is asked, if no record is found the pcap is deleted, otherwise normal processed.

If a record is waiting in the 2 hours timeout status in the field “status” the countdown proceed is shown, for example “P1443”, after 5 seconds “P1442” and so one (number*5/60 = time in minutes to zero).

To fix it just stop the recording, solve the problem if possible (if you are lucky for example the CDR data are in the PBX buffer and will be send to the reporting when connection is up again), if not save the Pcap file, at least it will not be deleted. Then delete the pcap file on the CF to avoid a slowdown of the entire system.

A simple but good idea is to enable the CDR on the recording trunk line, in this case “some information” for the call is retrieved all time and at least the system will not face that problem.

All described can be the result of a bad or erroneous setup, or the customer is aware of that and simply not interested in a good working application. So a “no record” answer could be a real alarm or not. Therefore in the setup that can be selected.

See recording setup, panel reporting, option “Alarm if no CDR ticket found”.

=== Asynchronous reporting/PBX date and time ===

PBX and reporting must have the same date and time. If not, the reporting will detect that and display error and warning messages about a possible manipulation in the files.

So check first the actual date and time of PBX and reporting.

IPVA: Remember that date can be set in the reporting in administration, General, Configure NTP server.

===Voice Recorder Window is truncated===

It could happen that the Voice Recorder Window is truncated. The reason for this is the screen resolution setting in windows. To solve the problem, the screen resolution adaption must be switched off (set to 100%) in windows system settings.

== Related Articles ==

[[Reference10:Player_Voice_Recording]]

[[Reference10:Voice_Recorder/Setup]]

[[Howto:Last_Call_Recording]]

[[Howto:Universal_Track_Recording_Tool]]

[[Howto:Integration_reporting_and_voice_recording]]

[[Howto:Soft-migration_%28looping_in_a_innovaphone_gateway%29_and_Voice_Recording]]

[[Howto:Player_over_http]]

[[Howto:Marking_a_record_in_Voicerecording]]

[[Howto:Voice_Recording_in_Master_Slave_scenarios]]

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

Support with TeamViewer

2015-07-15T05:32:35Z

Nfinzel: /* Download */

For more efficient support, innovaphone applies a remote support strategy using the familiar [http://www.teamviewer.com TeamViewer] utility. This allows our support personal to access the installation online under the customers full control. Here is how it works.

== Setup ==
To allow access to the installation, the customer needs to start the teamviewer client component on a machine that is located in the installation network. This can be just any PC ''with internet access''. There is no formal installation required to start the tool, so no administrator rights are required.

Access to the installation is possible only as long as the tool is running, and the customer has full visibility of what is going on during the session. The customer can hand over control to the support personal and the support personal can share their own desktop with the customer. Filetransfer is possible under the customers control.

=== Download ===
To start the session, simply download [http://www.innovaphone.com/Demo/innovaphone_RemoteSupport-idcnccnyth.exe the client executable] from '''http://www.innovaphone.com/Demo/innovaphone_RemoteSupport-idcnccnyth.exe'''.

=== Allowing access ===
A session ID and a password will be generated specifically for this session and the customer needs to share both with the support personal.

[[Image:Innovaphone RemoteSupport TeamViewer 01.png]]

== Permanent remote control access ==
It can be useful in certain situations to allow permanent remote access to servers, even across re-boots. This requires special installation. Discuss with innovaphone support personal if need be.

Howto:Switzerland - Sunrise Business voice - SIP Provider(2015)

2015-07-07T09:23:11Z

Nfinzel: /* Summary */

[[Image:3rdPartyGoldfischglas 03.png|right]]
[[Image:sunrise_logo_alg.png|100px|right]]

==Product Name==

[http://www1.sunrise.ch/Business-voice-cbAIHAqFI.QDEAAAEtwudBii1S-Sunrise-Business-Site-WFS-de_CH-CHF.html '''Business voice''']

== Current test state ==









{{Template:Compat Status "certified"|certificate=Sunrise_Business_Connect_-_SIP_Provider_-_product-cert.pdf}}

Testing of this product has been finalized July, 2015.

==Category==

{{Category:3rdParty SIP Provider}}
[[Category:RecProd|{{PAGENAME}}]]
[[Category:3rdParty SIP Provider|{{PAGENAME}}]]

==Version==

V11

==Vendor==

[[Image:sunrise_logo_org.png]]

[https://www.sunrise.ch ''sunrise'']

== Summary ==

[http://www1.sunrise.ch/Business-voice-cbAIHAqFI.QDEAAAEtwudBii1S-Sunrise-Business-Site-WFS-de_CH-CHF.html '''SIP Provider: Sunrise Business voice''']

The provider supports all mandatory innovaphone features and is therefore qualified as [[Howto:What_is_a_%22recommended_product%22%3F#SIP_Provider|recommended SIP Provider]].

That being said, the provider has achieved 86,34% of all possible test points (139 of 161). For more information on the test rating, please refer to [[Howto:SIP_Interop_Test_Description#|Test Description V11 and later]]

'''Please Note, that some features are restricted or not supported by Sunrise'''
* The T.38 feature is not available
* Fax via G.711 (T.38 to G.711 / Audio Fax support) is supported by Sunrise and work in most scenarios.
* Only G.711a, G.711u is supported, in special cases G.729 is supported, no other codecs are supported
* Overlapped Sending is not supported
* NAT Detection is not supported
* Redundancy Mechanism are supported when using two Sunrise Gateways
* SIP over TCP and SIP over TLS is not supported
* Call using SRTP are not supported

'''Sunrise doesn't support "Reverse Media negotiation". Because of this, "Media-Relay" and an "Exclusive Coder Setting" must be configured.''' In contrast to a SIP trunk which does not need Media-Relay, the transport of all RTP packets across the gateway will result in a higher CPU load.

In order to use some Features like[[Howto:How_does_CLIP_no_screening_work | Clip no screening]], some [[Howto:Sunrise_Business_voice_-_SIP_Trunk_-_SIP_Provider_Compatibility_Test#Configuration|configuration]] must be done.

Supported Features:
* Direct Dial In
* DTMF
* CGPN can be suppressed
* CLIP No Screening
* Hold/Retrieve
* Blind Transfer

Supported Codecs:
* G.711a, G.711u and in special cases G.729 only

[[Howto:Sunrise_Business_voice_-_SIP_Trunk_-_SIP_Provider_Compatibility_Test | Sunrise Test-report]]

==Contact==


For further informations on this test, please contact [http://www.sunrise.ch Sunrise].

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

File:SunriseSIPProviderTestTopology.png

2015-07-03T13:29:11Z

Nfinzel:

Howto:Sunrise Business voice - SIP Trunk - SIP Provider Compatibility Test

2015-07-03T12:02:35Z

Nfinzel: /* Current test state */

'''Innovaphone Compatibility Test Report'''

== Summary ==

'''SIP Provider: Sunrise Business voice'''

The provider supports all mandatory innovaphone features and is therefore qualified as [[Howto:What_is_a_%22recommended_product%22%3F#SIP_Provider|recommended SIP Provider]].

That being said, the provider has achieved 86,34% of all possible test points (139 of 161). For more information on the test rating, please refer to [[Howto:SIP_Interop_Test_Description|Test Description V11 and later]]

'''Please Note, that some features are restricted or not supported by Sunrise'''
** The T.38 feature is not available
** Fax via G.711 (T.38 to G.711 / Audio Fax support) is supported by Sunrise and work in most scenarios.
* Only G.711a, G.711u is supported, in special cases G.729 is supported, no other codecs are supported
* Overlapped Sending is not supported
* NAT Detection is not supported
* Redundancy Mechanism are supported when using two Sunrise Gateways
* SIP over TCP and SIP over TLS is not supported
* Call using STP are not supported

'''Sunrise doesn't support "Reverse Media negotiation". Because of this, "Media-Relay" and an "Exclusive Coder Setting" must be configured.''' In contrast to a SIP trunk which does not need Media-Relay, the transport of all RTP packets across the gateway will result in a higher CPU load.

In order to use some Features like[[Howto:How_does_CLIP_no_screening_work | Clip no screening]], some [[Howto:Sunrise_Business_voice_-_SIP_Trunk_-_SIP_Provider_Compatibility_Test#Configuration|configuration]] must be done.

Supported Features:
* Direct Dial In
* DTMF
* CGPN can be suppressed
* CLIP No Screening
* Hold/Retrieve
* Blind Transfer

Supported Codecs:
* G.711a, G.711u and in special cases G.729 only

== Current test state ==










{{Template:Compat Status "certified"|certificate=Sunrise_Business_Connect_-_SIP_Provider_-_product-cert.pdf}}

Testing of this product has been finalized July 2015.

== Testing Enviroment ==

[[Image:SunriseSIPProviderTestTopology1.png]]

This scenario describes a setup where the PBX and phones are in a private network.

Sunrise is providing an own Gateway ("SBC") which must be located in the customers private network. This Gateway has two connections:
* One connection to Sunrise
* One connection to the PBX
Because of this, the SIP Trunk does not connect directly to the internet, but to the Sunrise Gateway ("SBC").

The SIP trunk must be configured with "Media Relay", "exclusive G.711a" and "NO T.38".

[[Howto:Sunrise_Business_voice_-_SIP_Trunk_-_SIP_Provider_Compatibility_Test#Configuration|See configuration]]

== Test Results ==

For more information on the test procedure, please read the following wiki article: [[Howto:SIP_Interop_Test_Description|Test Description V11 and later]]. Bold lines in the test results indicate a KO-criteria.

(*1) In special cases G.729 is supported, must be booked and enabled at Sunrise

(*2) Fax via G.711 (T.38 to G.711 / Audio Fax support) is supported by Sunrise and work in most scenarios.

(*3) While Sunrise do not offer a second ip address on the same port as the gateway, Sunrise offers a dual homing solution involving two SBCs configured on one account.

=== Basic Call ===

{| border="1"
!Tested feature
!Result
|----
|'''call using g711a'''
|'''OK'''
|----
|'''call using g711u'''
|'''OK'''
|----
|call using g723
|NA
|----
|call using g729
|'''OK''' (*1)
|----
|call using g722
|NA
|----
|Overlapped sending
|NA
|----
|'''early media channel outgoing'''
|'''OK'''
|----
|Fax using T.38
|NA
|----
|T.38 Transcoding by the provider
|NA
|----
|Fax using G.711
|OK (*2)
|----
|Reverse Media Negotiation
|NOK
|----
|CGPN can be suppressed
|OK
|----
|CLIP no screening
|OK
|----
|'''Long time call possible(>30 min)'''
|'''OK'''
|----
|'''External Transfer'''
|'''OK'''
|----
|NAT Detection
|NA
|----
|Redundancy
|OK (*3)
|----
|SIP over TCP
|NA
|----
|'''Voice Quality OK?'''
|'''OK'''
|}

=== Direct Dial In ===

{| border="1"
!Tested feature
!Result
|----
|'''Inbound(Provider -> Innovaphone)'''
|'''OK'''
|----
|'''Outbound(Innovaphone -> Provider)'''
|'''OK'''
|----
|'''Loop In call(Innovaphone -> Provider -> Innovaphone)'''
|'''OK'''
|}

=== DTMF ===

{| border="1"
!Tested feature
!Result
|----
|'''DTMF tones sent correctly via RTP-events(RFC 2833)'''
|'''OK'''
|----
|DTMF tones sent correctly via SIP-Info
|OK
|----
|'''DTMF tones received correctly via RTP-events(RFC 2833)'''
|'''OK'''
|}

=== Hold/Retrieve ===

{| border="1"
!Tested feature
!Result
|----
|'''Call can be put on hold'''
|'''OK'''
|----
|Held end hears music on hold / announcement from PBX
|OK
|}

=== Transfer with consultation ===

{| border="1"
!Tested feature
!Result
|----
|'''Call can be transferred'''
|'''OK'''
|----
|Held end hears music on hold
|OK
|}

The following tests are made to test if call transfer is working.

{| border="1"
!Tested feature
!Voice Ok?
!MoH Ok?
|----
|inno1 calls inno2. inno2 transfers to PSTN-phone.
|OK
|OK
|----
|inno1 calls PSTN-phone. inno1 transfers to inno2.
|OK
|OK
|----
|inno1 calls PSTN-phone. PSTN-phone transfers to inno2.
|OK
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to inno2.
|OK
|OK
|----
|PSTN-phone calls inno1. PSTN-phone transfers to inno2.
|OK
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to other PSTN-phone-2.
|OK
|OK
|}

=== Transfer with consultation (alerting only) ===

{| border="1"
!Tested feature
!Result
|----
|'''Call can be transferred'''
|'''OK'''
|----
|Held end hears music on hold or dialling tone
|OK
|----
|'''Call returns to transferring device if the third'''
'''Endpoint is not available'''
|'''OK'''
|}

The following tests are made to test if call transfer is working.

{| border="1"
!Tested feature
!Voice Ok?
!MoH Ok?
|----
|inno1 calls inno2. inno2 transfers to PSTN-phone.
|OK
|OK
|----
|inno1 calls PSTN-phone. inno1 transfers to inno2.
|OK
|OK
|----
|inno1 calls PSTN-phone. PSTN-phone transfers to inno2.
|OK
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to inno2.
|OK
|OK
|----
|PSTN-phone calls inno1. PSTN-phone transfers to inno2.
|OK
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to other PSTN-phone-2.
|OK
|OK
|}

=== Blind Transfer ===

{| border="1"
!Tested feature
!Result
|----
|Call can be transferred
|OK
|----
|Held end hears dialling tone
|OK
|}

The following tests are made to test if call transfer is working.

{| border="1"
!Tested feature
!Voice Ok?
|----
|inno1 calls inno2. inno2 transfers to PSTN-phone.
|OK
|----
|inno1 calls PSTN-phone. inno1 transfers to inno2.
|OK
|----
|inno1 calls PSTN-phone. PSTN-phone transfers to inno2.
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to inno2.
|OK
|----
|PSTN-phone calls inno1. PSTN-phone transfers to inno2.
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to other PSTN-phone-2.
|OK
|}

=== CFU / CFB Transfer ===

{| border="1"
!Tested feature
!Result
|----
|'''Call can be forward'''
|'''OK'''
|----
|'''Held end hears dialling tone'''
|'''OK'''
|}

=== CFNR / Blind Transfer (alerting only)===

{| border="1"
!Tested feature
!Result
|----
|'''Call can be transferred or forward'''
|'''OK'''
|----
|'''Held end hears dialling tone'''
|'''OK'''
|}

The following tests are made to test if call transfer is working.

{| border="1"
!Tested feature
!Voice Ok?
|----
|inno1 calls inno2. inno2 transfers to PSTN-phone.
|OK
|----
|inno1 calls PSTN-phone. PSTN-phone transfers to inno2.
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to inno2.
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to other PSTN-phone-2.
|OK
|}

=== Broadcast Group & Waiting Queue ===

{| border="1"
!Tested feature
!Result
|----
|'''Caller can make a call to a Broadcast Group'''
|'''OK'''
|----
|'''Caller can make a call to a Waiting Queue'''
|'''OK'''
|----
|'''Announcement if nobody picks up the call'''
|'''OK'''
|}

== Configuration ==

===Firmware version===

All innovaphone devices use V11 build 11.3127 as firmware during test.

=== SIP - Trunk ===
Following configuration needs to be done in the SIP Gateway Interface settings:

* 1: Use "Gateway without Registration" as "Mode"
* 2: Enter the IP address of Sunrise SBC for "Remote Domain"
* 3: Enter the IP address of the innovaphone Gateway for "Local Domain"
* 4: Enter the IP address of Sunrise SBC for "Proxy"
* 5: Select G.711a as coder 20ms as Framsize and Exclusive
* 6: Disable "T.38", Enable Media-Relay" and No ICE"
* 7: Disable encryption
* 6: Use "Fixed AOR" in "From Header" and "CGPN in user part of URI" in "Identity Header"

[[Image:SunriseSIPProviderTestConfig1.png]]

=== Number Mapping ===
Following configuration needs to be done in the SIP Gateway Number Mappings:

* 1: Because Sunrise is using the full national number for incoming calls, you need to cut off the digits before an extension. In example, 04450199xx will be translated to xx.

[[Image:SunriseSIPProviderTestConfig2.png]]

=== Route Settings ===
A default Route Setup is used:

* 1: Force Enblock Setting is required for outgoing calls.

[[Image:SunriseSIPProviderTestConfig3.png]]

=== Fax ===
'''Sunrise does not support Fax communications with T.38.''' Because of this, T.38 can not be used.

If you want to use our Faxserver, you need to set T.38 to G.711 translation (Audio Fax support, available from V11). This works in a lot of cases where you have no problems with QoS.

Example to set T.38 to G.711 translation (Audio Fax support) on the Faxserver interface:

[[Image:SunriseSIPProviderTestConfig4.png]]

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

File:Sunrise Business voice Sunrise SIP Provider - product-cert.pdf

2015-07-03T11:54:32Z

Nfinzel:

File:Sunrise Business Connect - SIP Provider - product-cert.pdf

2015-07-03T11:53:44Z

Nfinzel:

Howto:Switzerland - Sunrise Business voice - SIP Provider(2015)

2015-07-03T11:53:05Z

Nfinzel: /* Current test state */

[[Image:3rdPartyGoldfischglas 03.png|right]]
[[Image:sunrise_logo_alg.png|100px|right]]

==Product Name==

[http://www1.sunrise.ch/Business-voice-cbAIHAqFI.QDEAAAEtwudBii1S-Sunrise-Business-Site-WFS-de_CH-CHF.html '''Business voice''']

== Current test state ==









{{Template:Compat Status "certified"|certificate=Sunrise_Business_Connect_-_SIP_Provider_-_product-cert.pdf}}

Testing of this product has been finalized July, 2015.

==Category==

{{Category:3rdParty SIP Provider}}
[[Category:RecProd|{{PAGENAME}}]]
[[Category:3rdParty SIP Provider|{{PAGENAME}}]]

==Version==

V11

==Vendor==

[[Image:sunrise_logo_org.png]]

[https://www.sunrise.ch ''sunrise'']

== Summary ==

[http://www1.sunrise.ch/Business-voice-cbAIHAqFI.QDEAAAEtwudBii1S-Sunrise-Business-Site-WFS-de_CH-CHF.html '''SIP Provider: Sunrise Business voice''']

The provider supports all mandatory innovaphone features and is therefore qualified as [[Howto:What_is_a_%22recommended_product%22%3F#SIP_Provider|recommended SIP Provider]].

That being said, the provider has achieved 86,34% of all possible test points (139 of 161). For more information on the test rating, please refer to [[Howto:SIP_Interop_Test_Description#|Test Description V11 and later]]

'''Please Note, that some features are restricted or not supported by Sunrise'''
** The T.38 feature is not available
** Fax via G.711 (T.38 to G.711 / Audio Fax support) is supported by Sunrise and work in most scenarios.
* Only G.711a, G.711u is supported, in special cases G.729 is supported, no other codecs are supported
* Overlapped Sending is not supported
* NAT Detection is not supported
* Redundancy Mechanism are supported when using two Sunrise Gateways
* SIP over TCP and SIP over TLS is not supported
* Call using STP are not supported

'''Sunrise doesn't support "Reverse Media negotiation". Because of this, "Media-Relay" and an "Exclusive Coder Setting" must be configured.''' In contrast to a SIP trunk which does not need Media-Relay, the transport of all RTP packets across the gateway will result in a higher CPU load.

In order to use some Features like[[Howto:How_does_CLIP_no_screening_work | Clip no screening]], some [[Howto:Sunrise_Business_voice_-_SIP_Trunk_-_SIP_Provider_Compatibility_Test#Configuration|configuration]] must be done.

Supported Features:
* Direct Dial In
* DTMF
* CGPN can be suppressed
* CLIP No Screening
* Hold/Retrieve
* Blind Transfer

Supported Codecs:
* G.711a, G.711u and in special cases G.729 only

[[Howto:Sunrise_Business_voice_-_SIP_Trunk_-_SIP_Provider_Compatibility_Test | Sunrise Test-report]]

==Contact==


For further informations on this test, please contact [http://www.sunrise.ch Sunrise].

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

Howto:Switzerland - Sunrise Business voice - SIP Provider(2015)

2015-07-03T11:52:26Z

Nfinzel: /* Current test state */

[[Image:3rdPartyGoldfischglas 03.png|right]]
[[Image:sunrise_logo_alg.png|100px|right]]

==Product Name==

[http://www1.sunrise.ch/Business-voice-cbAIHAqFI.QDEAAAEtwudBii1S-Sunrise-Business-Site-WFS-de_CH-CHF.html '''Business voice''']

== Current test state ==









{{Template:Compat Status "certified"|certificate=Swisscom_Business_Connect_-_SIP_Provider_-_product-cert.pdf}}

Testing of this product has been finalized July, 2015.

==Category==

{{Category:3rdParty SIP Provider}}
[[Category:RecProd|{{PAGENAME}}]]
[[Category:3rdParty SIP Provider|{{PAGENAME}}]]

==Version==

V11

==Vendor==

[[Image:sunrise_logo_org.png]]

[https://www.sunrise.ch ''sunrise'']

== Summary ==

[http://www1.sunrise.ch/Business-voice-cbAIHAqFI.QDEAAAEtwudBii1S-Sunrise-Business-Site-WFS-de_CH-CHF.html '''SIP Provider: Sunrise Business voice''']

The provider supports all mandatory innovaphone features and is therefore qualified as [[Howto:What_is_a_%22recommended_product%22%3F#SIP_Provider|recommended SIP Provider]].

That being said, the provider has achieved 86,34% of all possible test points (139 of 161). For more information on the test rating, please refer to [[Howto:SIP_Interop_Test_Description#|Test Description V11 and later]]

'''Please Note, that some features are restricted or not supported by Sunrise'''
** The T.38 feature is not available
** Fax via G.711 (T.38 to G.711 / Audio Fax support) is supported by Sunrise and work in most scenarios.
* Only G.711a, G.711u is supported, in special cases G.729 is supported, no other codecs are supported
* Overlapped Sending is not supported
* NAT Detection is not supported
* Redundancy Mechanism are supported when using two Sunrise Gateways
* SIP over TCP and SIP over TLS is not supported
* Call using STP are not supported

'''Sunrise doesn't support "Reverse Media negotiation". Because of this, "Media-Relay" and an "Exclusive Coder Setting" must be configured.''' In contrast to a SIP trunk which does not need Media-Relay, the transport of all RTP packets across the gateway will result in a higher CPU load.

In order to use some Features like[[Howto:How_does_CLIP_no_screening_work | Clip no screening]], some [[Howto:Sunrise_Business_voice_-_SIP_Trunk_-_SIP_Provider_Compatibility_Test#Configuration|configuration]] must be done.

Supported Features:
* Direct Dial In
* DTMF
* CGPN can be suppressed
* CLIP No Screening
* Hold/Retrieve
* Blind Transfer

Supported Codecs:
* G.711a, G.711u and in special cases G.729 only

[[Howto:Sunrise_Business_voice_-_SIP_Trunk_-_SIP_Provider_Compatibility_Test | Sunrise Test-report]]

==Contact==


For further informations on this test, please contact [http://www.sunrise.ch Sunrise].

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

Howto:Switzerland - Sunrise Business voice - SIP Provider(2015)

2015-07-03T11:51:38Z

Nfinzel: New page:   <!-- to create a new entry here, - fill in all sections marked a...

[[Image:3rdPartyGoldfischglas 03.png|right]]
[[Image:sunrise_logo_alg.png|100px|right]]

==Product Name==

[http://www1.sunrise.ch/Business-voice-cbAIHAqFI.QDEAAAEtwudBii1S-Sunrise-Business-Site-WFS-de_CH-CHF.html '''Business voice''']

== Current test state ==


{{Template:Compat Status "in progress"}}








Testing of this product has been finalized July, 2015.

==Category==

{{Category:3rdParty SIP Provider}}
[[Category:RecProd|{{PAGENAME}}]]
[[Category:3rdParty SIP Provider|{{PAGENAME}}]]

==Version==

V11

==Vendor==

[[Image:sunrise_logo_org.png]]

[https://www.sunrise.ch ''sunrise'']

== Summary ==

[http://www1.sunrise.ch/Business-voice-cbAIHAqFI.QDEAAAEtwudBii1S-Sunrise-Business-Site-WFS-de_CH-CHF.html '''SIP Provider: Sunrise Business voice''']

The provider supports all mandatory innovaphone features and is therefore qualified as [[Howto:What_is_a_%22recommended_product%22%3F#SIP_Provider|recommended SIP Provider]].

That being said, the provider has achieved 86,34% of all possible test points (139 of 161). For more information on the test rating, please refer to [[Howto:SIP_Interop_Test_Description#|Test Description V11 and later]]

'''Please Note, that some features are restricted or not supported by Sunrise'''
** The T.38 feature is not available
** Fax via G.711 (T.38 to G.711 / Audio Fax support) is supported by Sunrise and work in most scenarios.
* Only G.711a, G.711u is supported, in special cases G.729 is supported, no other codecs are supported
* Overlapped Sending is not supported
* NAT Detection is not supported
* Redundancy Mechanism are supported when using two Sunrise Gateways
* SIP over TCP and SIP over TLS is not supported
* Call using STP are not supported

'''Sunrise doesn't support "Reverse Media negotiation". Because of this, "Media-Relay" and an "Exclusive Coder Setting" must be configured.''' In contrast to a SIP trunk which does not need Media-Relay, the transport of all RTP packets across the gateway will result in a higher CPU load.

In order to use some Features like[[Howto:How_does_CLIP_no_screening_work | Clip no screening]], some [[Howto:Sunrise_Business_voice_-_SIP_Trunk_-_SIP_Provider_Compatibility_Test#Configuration|configuration]] must be done.

Supported Features:
* Direct Dial In
* DTMF
* CGPN can be suppressed
* CLIP No Screening
* Hold/Retrieve
* Blind Transfer

Supported Codecs:
* G.711a, G.711u and in special cases G.729 only

[[Howto:Sunrise_Business_voice_-_SIP_Trunk_-_SIP_Provider_Compatibility_Test | Sunrise Test-report]]

==Contact==


For further informations on this test, please contact [http://www.sunrise.ch Sunrise].

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

File:Sunrise logo alg.png

2015-07-03T11:47:01Z

Nfinzel:

File:Sunrise logo org.png

2015-07-03T11:46:06Z

Nfinzel:

Howto:Sunrise Business voice - SIP Trunk - SIP Provider Compatibility Test

2015-07-03T11:43:12Z

Nfinzel: /* Test Results */

'''Innovaphone Compatibility Test Report'''

== Summary ==

'''SIP Provider: Sunrise Business voice'''

The provider supports all mandatory innovaphone features and is therefore qualified as [[Howto:What_is_a_%22recommended_product%22%3F#SIP_Provider|recommended SIP Provider]].

That being said, the provider has achieved 86,34% of all possible test points (139 of 161). For more information on the test rating, please refer to [[Howto:SIP_Interop_Test_Description|Test Description V11 and later]]

'''Please Note, that some features are restricted or not supported by Sunrise'''
** The T.38 feature is not available
** Fax via G.711 (T.38 to G.711 / Audio Fax support) is supported by Sunrise and work in most scenarios.
* Only G.711a, G.711u is supported, in special cases G.729 is supported, no other codecs are supported
* Overlapped Sending is not supported
* NAT Detection is not supported
* Redundancy Mechanism are supported when using two Sunrise Gateways
* SIP over TCP and SIP over TLS is not supported
* Call using STP are not supported

'''Sunrise doesn't support "Reverse Media negotiation". Because of this, "Media-Relay" and an "Exclusive Coder Setting" must be configured.''' In contrast to a SIP trunk which does not need Media-Relay, the transport of all RTP packets across the gateway will result in a higher CPU load.

In order to use some Features like[[Howto:How_does_CLIP_no_screening_work | Clip no screening]], some [[Howto:Sunrise_Business_voice_-_SIP_Trunk_-_SIP_Provider_Compatibility_Test#Configuration|configuration]] must be done.

Supported Features:
* Direct Dial In
* DTMF
* CGPN can be suppressed
* CLIP No Screening
* Hold/Retrieve
* Blind Transfer

Supported Codecs:
* G.711a, G.711u and in special cases G.729 only

== Current test state ==

{{Template:Compat Status "in progress"}}










Testing of this product has been finalized July 2015.

== Testing Enviroment ==

[[Image:SunriseSIPProviderTestTopology1.png]]

This scenario describes a setup where the PBX and phones are in a private network.

Sunrise is providing an own Gateway ("SBC") which must be located in the customers private network. This Gateway has two connections:
* One connection to Sunrise
* One connection to the PBX
Because of this, the SIP Trunk does not connect directly to the internet, but to the Sunrise Gateway ("SBC").

The SIP trunk must be configured with "Media Relay", "exclusive G.711a" and "NO T.38".

[[Howto:Sunrise_Business_voice_-_SIP_Trunk_-_SIP_Provider_Compatibility_Test#Configuration|See configuration]]

== Test Results ==

For more information on the test procedure, please read the following wiki article: [[Howto:SIP_Interop_Test_Description|Test Description V11 and later]]. Bold lines in the test results indicate a KO-criteria.

(*1) In special cases G.729 is supported, must be booked and enabled at Sunrise

(*2) Fax via G.711 (T.38 to G.711 / Audio Fax support) is supported by Sunrise and work in most scenarios.

(*3) While Sunrise do not offer a second ip address on the same port as the gateway, Sunrise offers a dual homing solution involving two SBCs configured on one account.

=== Basic Call ===

{| border="1"
!Tested feature
!Result
|----
|'''call using g711a'''
|'''OK'''
|----
|'''call using g711u'''
|'''OK'''
|----
|call using g723
|NA
|----
|call using g729
|'''OK''' (*1)
|----
|call using g722
|NA
|----
|Overlapped sending
|NA
|----
|'''early media channel outgoing'''
|'''OK'''
|----
|Fax using T.38
|NA
|----
|T.38 Transcoding by the provider
|NA
|----
|Fax using G.711
|OK (*2)
|----
|Reverse Media Negotiation
|NOK
|----
|CGPN can be suppressed
|OK
|----
|CLIP no screening
|OK
|----
|'''Long time call possible(>30 min)'''
|'''OK'''
|----
|'''External Transfer'''
|'''OK'''
|----
|NAT Detection
|NA
|----
|Redundancy
|OK (*3)
|----
|SIP over TCP
|NA
|----
|'''Voice Quality OK?'''
|'''OK'''
|}

=== Direct Dial In ===

{| border="1"
!Tested feature
!Result
|----
|'''Inbound(Provider -> Innovaphone)'''
|'''OK'''
|----
|'''Outbound(Innovaphone -> Provider)'''
|'''OK'''
|----
|'''Loop In call(Innovaphone -> Provider -> Innovaphone)'''
|'''OK'''
|}

=== DTMF ===

{| border="1"
!Tested feature
!Result
|----
|'''DTMF tones sent correctly via RTP-events(RFC 2833)'''
|'''OK'''
|----
|DTMF tones sent correctly via SIP-Info
|OK
|----
|'''DTMF tones received correctly via RTP-events(RFC 2833)'''
|'''OK'''
|}

=== Hold/Retrieve ===

{| border="1"
!Tested feature
!Result
|----
|'''Call can be put on hold'''
|'''OK'''
|----
|Held end hears music on hold / announcement from PBX
|OK
|}

=== Transfer with consultation ===

{| border="1"
!Tested feature
!Result
|----
|'''Call can be transferred'''
|'''OK'''
|----
|Held end hears music on hold
|OK
|}

The following tests are made to test if call transfer is working.

{| border="1"
!Tested feature
!Voice Ok?
!MoH Ok?
|----
|inno1 calls inno2. inno2 transfers to PSTN-phone.
|OK
|OK
|----
|inno1 calls PSTN-phone. inno1 transfers to inno2.
|OK
|OK
|----
|inno1 calls PSTN-phone. PSTN-phone transfers to inno2.
|OK
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to inno2.
|OK
|OK
|----
|PSTN-phone calls inno1. PSTN-phone transfers to inno2.
|OK
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to other PSTN-phone-2.
|OK
|OK
|}

=== Transfer with consultation (alerting only) ===

{| border="1"
!Tested feature
!Result
|----
|'''Call can be transferred'''
|'''OK'''
|----
|Held end hears music on hold or dialling tone
|OK
|----
|'''Call returns to transferring device if the third'''
'''Endpoint is not available'''
|'''OK'''
|}

The following tests are made to test if call transfer is working.

{| border="1"
!Tested feature
!Voice Ok?
!MoH Ok?
|----
|inno1 calls inno2. inno2 transfers to PSTN-phone.
|OK
|OK
|----
|inno1 calls PSTN-phone. inno1 transfers to inno2.
|OK
|OK
|----
|inno1 calls PSTN-phone. PSTN-phone transfers to inno2.
|OK
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to inno2.
|OK
|OK
|----
|PSTN-phone calls inno1. PSTN-phone transfers to inno2.
|OK
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to other PSTN-phone-2.
|OK
|OK
|}

=== Blind Transfer ===

{| border="1"
!Tested feature
!Result
|----
|Call can be transferred
|OK
|----
|Held end hears dialling tone
|OK
|}

The following tests are made to test if call transfer is working.

{| border="1"
!Tested feature
!Voice Ok?
|----
|inno1 calls inno2. inno2 transfers to PSTN-phone.
|OK
|----
|inno1 calls PSTN-phone. inno1 transfers to inno2.
|OK
|----
|inno1 calls PSTN-phone. PSTN-phone transfers to inno2.
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to inno2.
|OK
|----
|PSTN-phone calls inno1. PSTN-phone transfers to inno2.
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to other PSTN-phone-2.
|OK
|}

=== CFU / CFB Transfer ===

{| border="1"
!Tested feature
!Result
|----
|'''Call can be forward'''
|'''OK'''
|----
|'''Held end hears dialling tone'''
|'''OK'''
|}

=== CFNR / Blind Transfer (alerting only)===

{| border="1"
!Tested feature
!Result
|----
|'''Call can be transferred or forward'''
|'''OK'''
|----
|'''Held end hears dialling tone'''
|'''OK'''
|}

The following tests are made to test if call transfer is working.

{| border="1"
!Tested feature
!Voice Ok?
|----
|inno1 calls inno2. inno2 transfers to PSTN-phone.
|OK
|----
|inno1 calls PSTN-phone. PSTN-phone transfers to inno2.
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to inno2.
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to other PSTN-phone-2.
|OK
|}

=== Broadcast Group & Waiting Queue ===

{| border="1"
!Tested feature
!Result
|----
|'''Caller can make a call to a Broadcast Group'''
|'''OK'''
|----
|'''Caller can make a call to a Waiting Queue'''
|'''OK'''
|----
|'''Announcement if nobody picks up the call'''
|'''OK'''
|}

== Configuration ==

===Firmware version===

All innovaphone devices use V11 build 11.3127 as firmware during test.

=== SIP - Trunk ===
Following configuration needs to be done in the SIP Gateway Interface settings:

* 1: Use "Gateway without Registration" as "Mode"
* 2: Enter the IP address of Sunrise SBC for "Remote Domain"
* 3: Enter the IP address of the innovaphone Gateway for "Local Domain"
* 4: Enter the IP address of Sunrise SBC for "Proxy"
* 5: Select G.711a as coder 20ms as Framsize and Exclusive
* 6: Disable "T.38", Enable Media-Relay" and No ICE"
* 7: Disable encryption
* 6: Use "Fixed AOR" in "From Header" and "CGPN in user part of URI" in "Identity Header"

[[Image:SunriseSIPProviderTestConfig1.png]]

=== Number Mapping ===
Following configuration needs to be done in the SIP Gateway Number Mappings:

* 1: Because Sunrise is using the full national number for incoming calls, you need to cut off the digits before an extension. In example, 04450199xx will be translated to xx.

[[Image:SunriseSIPProviderTestConfig2.png]]

=== Route Settings ===
A default Route Setup is used:

* 1: Force Enblock Setting is required for outgoing calls.

[[Image:SunriseSIPProviderTestConfig3.png]]

=== Fax ===
'''Sunrise does not support Fax communications with T.38.''' Because of this, T.38 can not be used.

If you want to use our Faxserver, you need to set T.38 to G.711 translation (Audio Fax support, available from V11). This works in a lot of cases where you have no problems with QoS.

Example to set T.38 to G.711 translation (Audio Fax support) on the Faxserver interface:

[[Image:SunriseSIPProviderTestConfig4.png]]

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

Howto:Sunrise Business voice - SIP Trunk - SIP Provider Compatibility Test

2015-07-03T11:42:49Z

Nfinzel: /* Summary */

'''Innovaphone Compatibility Test Report'''

== Summary ==

'''SIP Provider: Sunrise Business voice'''

The provider supports all mandatory innovaphone features and is therefore qualified as [[Howto:What_is_a_%22recommended_product%22%3F#SIP_Provider|recommended SIP Provider]].

That being said, the provider has achieved 86,34% of all possible test points (139 of 161). For more information on the test rating, please refer to [[Howto:SIP_Interop_Test_Description|Test Description V11 and later]]

'''Please Note, that some features are restricted or not supported by Sunrise'''
** The T.38 feature is not available
** Fax via G.711 (T.38 to G.711 / Audio Fax support) is supported by Sunrise and work in most scenarios.
* Only G.711a, G.711u is supported, in special cases G.729 is supported, no other codecs are supported
* Overlapped Sending is not supported
* NAT Detection is not supported
* Redundancy Mechanism are supported when using two Sunrise Gateways
* SIP over TCP and SIP over TLS is not supported
* Call using STP are not supported

'''Sunrise doesn't support "Reverse Media negotiation". Because of this, "Media-Relay" and an "Exclusive Coder Setting" must be configured.''' In contrast to a SIP trunk which does not need Media-Relay, the transport of all RTP packets across the gateway will result in a higher CPU load.

In order to use some Features like[[Howto:How_does_CLIP_no_screening_work | Clip no screening]], some [[Howto:Sunrise_Business_voice_-_SIP_Trunk_-_SIP_Provider_Compatibility_Test#Configuration|configuration]] must be done.

Supported Features:
* Direct Dial In
* DTMF
* CGPN can be suppressed
* CLIP No Screening
* Hold/Retrieve
* Blind Transfer

Supported Codecs:
* G.711a, G.711u and in special cases G.729 only

== Current test state ==

{{Template:Compat Status "in progress"}}










Testing of this product has been finalized July 2015.

== Testing Enviroment ==

[[Image:SunriseSIPProviderTestTopology1.png]]

This scenario describes a setup where the PBX and phones are in a private network.

Sunrise is providing an own Gateway ("SBC") which must be located in the customers private network. This Gateway has two connections:
* One connection to Sunrise
* One connection to the PBX
Because of this, the SIP Trunk does not connect directly to the internet, but to the Sunrise Gateway ("SBC").

The SIP trunk must be configured with "Media Relay", "exclusive G.711a" and "NO T.38".

[[Howto:Sunrise_Business_voice_-_SIP_Trunk_-_SIP_Provider_Compatibility_Test#Configuration|See configuration]]

== Test Results ==

For more information on the test procedure, please read the following wiki article: [[Howto:SIP_Interop_Test_Description_v11#|Test Description V11 and later]]. Bold lines in the test results indicate a KO-criteria.

(*1) In special cases G.729 is supported, must be booked and enabled at Sunrise

(*2) Fax via G.711 (T.38 to G.711 / Audio Fax support) is supported by Sunrise and work in most scenarios.

(*3) While Sunrise do not offer a second ip address on the same port as the gateway, Sunrise offers a dual homing solution involving two SBCs configured on one account.

=== Basic Call ===

{| border="1"
!Tested feature
!Result
|----
|'''call using g711a'''
|'''OK'''
|----
|'''call using g711u'''
|'''OK'''
|----
|call using g723
|NA
|----
|call using g729
|'''OK''' (*1)
|----
|call using g722
|NA
|----
|Overlapped sending
|NA
|----
|'''early media channel outgoing'''
|'''OK'''
|----
|Fax using T.38
|NA
|----
|T.38 Transcoding by the provider
|NA
|----
|Fax using G.711
|OK (*2)
|----
|Reverse Media Negotiation
|NOK
|----
|CGPN can be suppressed
|OK
|----
|CLIP no screening
|OK
|----
|'''Long time call possible(>30 min)'''
|'''OK'''
|----
|'''External Transfer'''
|'''OK'''
|----
|NAT Detection
|NA
|----
|Redundancy
|OK (*3)
|----
|SIP over TCP
|NA
|----
|'''Voice Quality OK?'''
|'''OK'''
|}

=== Direct Dial In ===

{| border="1"
!Tested feature
!Result
|----
|'''Inbound(Provider -> Innovaphone)'''
|'''OK'''
|----
|'''Outbound(Innovaphone -> Provider)'''
|'''OK'''
|----
|'''Loop In call(Innovaphone -> Provider -> Innovaphone)'''
|'''OK'''
|}

=== DTMF ===

{| border="1"
!Tested feature
!Result
|----
|'''DTMF tones sent correctly via RTP-events(RFC 2833)'''
|'''OK'''
|----
|DTMF tones sent correctly via SIP-Info
|OK
|----
|'''DTMF tones received correctly via RTP-events(RFC 2833)'''
|'''OK'''
|}

=== Hold/Retrieve ===

{| border="1"
!Tested feature
!Result
|----
|'''Call can be put on hold'''
|'''OK'''
|----
|Held end hears music on hold / announcement from PBX
|OK
|}

=== Transfer with consultation ===

{| border="1"
!Tested feature
!Result
|----
|'''Call can be transferred'''
|'''OK'''
|----
|Held end hears music on hold
|OK
|}

The following tests are made to test if call transfer is working.

{| border="1"
!Tested feature
!Voice Ok?
!MoH Ok?
|----
|inno1 calls inno2. inno2 transfers to PSTN-phone.
|OK
|OK
|----
|inno1 calls PSTN-phone. inno1 transfers to inno2.
|OK
|OK
|----
|inno1 calls PSTN-phone. PSTN-phone transfers to inno2.
|OK
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to inno2.
|OK
|OK
|----
|PSTN-phone calls inno1. PSTN-phone transfers to inno2.
|OK
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to other PSTN-phone-2.
|OK
|OK
|}

=== Transfer with consultation (alerting only) ===

{| border="1"
!Tested feature
!Result
|----
|'''Call can be transferred'''
|'''OK'''
|----
|Held end hears music on hold or dialling tone
|OK
|----
|'''Call returns to transferring device if the third'''
'''Endpoint is not available'''
|'''OK'''
|}

The following tests are made to test if call transfer is working.

{| border="1"
!Tested feature
!Voice Ok?
!MoH Ok?
|----
|inno1 calls inno2. inno2 transfers to PSTN-phone.
|OK
|OK
|----
|inno1 calls PSTN-phone. inno1 transfers to inno2.
|OK
|OK
|----
|inno1 calls PSTN-phone. PSTN-phone transfers to inno2.
|OK
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to inno2.
|OK
|OK
|----
|PSTN-phone calls inno1. PSTN-phone transfers to inno2.
|OK
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to other PSTN-phone-2.
|OK
|OK
|}

=== Blind Transfer ===

{| border="1"
!Tested feature
!Result
|----
|Call can be transferred
|OK
|----
|Held end hears dialling tone
|OK
|}

The following tests are made to test if call transfer is working.

{| border="1"
!Tested feature
!Voice Ok?
|----
|inno1 calls inno2. inno2 transfers to PSTN-phone.
|OK
|----
|inno1 calls PSTN-phone. inno1 transfers to inno2.
|OK
|----
|inno1 calls PSTN-phone. PSTN-phone transfers to inno2.
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to inno2.
|OK
|----
|PSTN-phone calls inno1. PSTN-phone transfers to inno2.
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to other PSTN-phone-2.
|OK
|}

=== CFU / CFB Transfer ===

{| border="1"
!Tested feature
!Result
|----
|'''Call can be forward'''
|'''OK'''
|----
|'''Held end hears dialling tone'''
|'''OK'''
|}

=== CFNR / Blind Transfer (alerting only)===

{| border="1"
!Tested feature
!Result
|----
|'''Call can be transferred or forward'''
|'''OK'''
|----
|'''Held end hears dialling tone'''
|'''OK'''
|}

The following tests are made to test if call transfer is working.

{| border="1"
!Tested feature
!Voice Ok?
|----
|inno1 calls inno2. inno2 transfers to PSTN-phone.
|OK
|----
|inno1 calls PSTN-phone. PSTN-phone transfers to inno2.
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to inno2.
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to other PSTN-phone-2.
|OK
|}

=== Broadcast Group & Waiting Queue ===

{| border="1"
!Tested feature
!Result
|----
|'''Caller can make a call to a Broadcast Group'''
|'''OK'''
|----
|'''Caller can make a call to a Waiting Queue'''
|'''OK'''
|----
|'''Announcement if nobody picks up the call'''
|'''OK'''
|}

== Configuration ==

===Firmware version===

All innovaphone devices use V11 build 11.3127 as firmware during test.

=== SIP - Trunk ===
Following configuration needs to be done in the SIP Gateway Interface settings:

* 1: Use "Gateway without Registration" as "Mode"
* 2: Enter the IP address of Sunrise SBC for "Remote Domain"
* 3: Enter the IP address of the innovaphone Gateway for "Local Domain"
* 4: Enter the IP address of Sunrise SBC for "Proxy"
* 5: Select G.711a as coder 20ms as Framsize and Exclusive
* 6: Disable "T.38", Enable Media-Relay" and No ICE"
* 7: Disable encryption
* 6: Use "Fixed AOR" in "From Header" and "CGPN in user part of URI" in "Identity Header"

[[Image:SunriseSIPProviderTestConfig1.png]]

=== Number Mapping ===
Following configuration needs to be done in the SIP Gateway Number Mappings:

* 1: Because Sunrise is using the full national number for incoming calls, you need to cut off the digits before an extension. In example, 04450199xx will be translated to xx.

[[Image:SunriseSIPProviderTestConfig2.png]]

=== Route Settings ===
A default Route Setup is used:

* 1: Force Enblock Setting is required for outgoing calls.

[[Image:SunriseSIPProviderTestConfig3.png]]

=== Fax ===
'''Sunrise does not support Fax communications with T.38.''' Because of this, T.38 can not be used.

If you want to use our Faxserver, you need to set T.38 to G.711 translation (Audio Fax support, available from V11). This works in a lot of cases where you have no problems with QoS.

Example to set T.38 to G.711 translation (Audio Fax support) on the Faxserver interface:

[[Image:SunriseSIPProviderTestConfig4.png]]

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

Howto:Sunrise Business voice - SIP Trunk - SIP Provider Compatibility Test

2015-07-03T11:37:08Z

Nfinzel: /* Summary */

'''Innovaphone Compatibility Test Report'''

== Summary ==

'''SIP Provider: Sunrise Business voice'''

The provider supports all mandatory innovaphone features and is therefore qualified as [[Howto:What_is_a_%22recommended_product%22%3F#SIP_Provider|recommended SIP Provider]].

That being said, the provider has achieved 86,34% of all possible test points (139 of 161). For more information on the test rating, please refer to [[Howto:SIP_Interop_Test_Description_v11#|Test Description V11 and later]]

'''Please Note, that some features are restricted or not supported by Sunrise'''
** The T.38 feature is not available
** Fax via G.711 (T.38 to G.711 / Audio Fax support) is supported by Sunrise and work in most scenarios.
* Only G.711a, G.711u is supported, in special cases G.729 is supported, no other codecs are supported
* Overlapped Sending is not supported
* NAT Detection is not supported
* Redundancy Mechanism are supported when using two Sunrise Gateways
* SIP over TCP and SIP over TLS is not supported
* Call using STP are not supported

'''Sunrise doesn't support "Reverse Media negotiation". Because of this, "Media-Relay" and an "Exclusive Coder Setting" must be configured.''' In contrast to a SIP trunk which does not need Media-Relay, the transport of all RTP packets across the gateway will result in a higher CPU load.

In order to use some Features like[[Howto:How_does_CLIP_no_screening_work | Clip no screening]], some [[Howto:Sunrise_Business_voice_-_SIP_Trunk_-_SIP_Provider_Compatibility_Test#Configuration|configuration]] must be done.

Supported Features:
* Direct Dial In
* DTMF
* CGPN can be suppressed
* CLIP No Screening
* Hold/Retrieve
* Blind Transfer

Supported Codecs:
* G.711a, G.711u and in special cases G.729 only

== Current test state ==

{{Template:Compat Status "in progress"}}










Testing of this product has been finalized July 2015.

== Testing Enviroment ==

[[Image:SunriseSIPProviderTestTopology1.png]]

This scenario describes a setup where the PBX and phones are in a private network.

Sunrise is providing an own Gateway ("SBC") which must be located in the customers private network. This Gateway has two connections:
* One connection to Sunrise
* One connection to the PBX
Because of this, the SIP Trunk does not connect directly to the internet, but to the Sunrise Gateway ("SBC").

The SIP trunk must be configured with "Media Relay", "exclusive G.711a" and "NO T.38".

[[Howto:Sunrise_Business_voice_-_SIP_Trunk_-_SIP_Provider_Compatibility_Test#Configuration|See configuration]]

== Test Results ==

For more information on the test procedure, please read the following wiki article: [[Howto:SIP_Interop_Test_Description_v11#|Test Description V11 and later]]. Bold lines in the test results indicate a KO-criteria.

(*1) In special cases G.729 is supported, must be booked and enabled at Sunrise

(*2) Fax via G.711 (T.38 to G.711 / Audio Fax support) is supported by Sunrise and work in most scenarios.

(*3) While Sunrise do not offer a second ip address on the same port as the gateway, Sunrise offers a dual homing solution involving two SBCs configured on one account.

=== Basic Call ===

{| border="1"
!Tested feature
!Result
|----
|'''call using g711a'''
|'''OK'''
|----
|'''call using g711u'''
|'''OK'''
|----
|call using g723
|NA
|----
|call using g729
|'''OK''' (*1)
|----
|call using g722
|NA
|----
|Overlapped sending
|NA
|----
|'''early media channel outgoing'''
|'''OK'''
|----
|Fax using T.38
|NA
|----
|T.38 Transcoding by the provider
|NA
|----
|Fax using G.711
|OK (*2)
|----
|Reverse Media Negotiation
|NOK
|----
|CGPN can be suppressed
|OK
|----
|CLIP no screening
|OK
|----
|'''Long time call possible(>30 min)'''
|'''OK'''
|----
|'''External Transfer'''
|'''OK'''
|----
|NAT Detection
|NA
|----
|Redundancy
|OK (*3)
|----
|SIP over TCP
|NA
|----
|'''Voice Quality OK?'''
|'''OK'''
|}

=== Direct Dial In ===

{| border="1"
!Tested feature
!Result
|----
|'''Inbound(Provider -> Innovaphone)'''
|'''OK'''
|----
|'''Outbound(Innovaphone -> Provider)'''
|'''OK'''
|----
|'''Loop In call(Innovaphone -> Provider -> Innovaphone)'''
|'''OK'''
|}

=== DTMF ===

{| border="1"
!Tested feature
!Result
|----
|'''DTMF tones sent correctly via RTP-events(RFC 2833)'''
|'''OK'''
|----
|DTMF tones sent correctly via SIP-Info
|OK
|----
|'''DTMF tones received correctly via RTP-events(RFC 2833)'''
|'''OK'''
|}

=== Hold/Retrieve ===

{| border="1"
!Tested feature
!Result
|----
|'''Call can be put on hold'''
|'''OK'''
|----
|Held end hears music on hold / announcement from PBX
|OK
|}

=== Transfer with consultation ===

{| border="1"
!Tested feature
!Result
|----
|'''Call can be transferred'''
|'''OK'''
|----
|Held end hears music on hold
|OK
|}

The following tests are made to test if call transfer is working.

{| border="1"
!Tested feature
!Voice Ok?
!MoH Ok?
|----
|inno1 calls inno2. inno2 transfers to PSTN-phone.
|OK
|OK
|----
|inno1 calls PSTN-phone. inno1 transfers to inno2.
|OK
|OK
|----
|inno1 calls PSTN-phone. PSTN-phone transfers to inno2.
|OK
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to inno2.
|OK
|OK
|----
|PSTN-phone calls inno1. PSTN-phone transfers to inno2.
|OK
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to other PSTN-phone-2.
|OK
|OK
|}

=== Transfer with consultation (alerting only) ===

{| border="1"
!Tested feature
!Result
|----
|'''Call can be transferred'''
|'''OK'''
|----
|Held end hears music on hold or dialling tone
|OK
|----
|'''Call returns to transferring device if the third'''
'''Endpoint is not available'''
|'''OK'''
|}

The following tests are made to test if call transfer is working.

{| border="1"
!Tested feature
!Voice Ok?
!MoH Ok?
|----
|inno1 calls inno2. inno2 transfers to PSTN-phone.
|OK
|OK
|----
|inno1 calls PSTN-phone. inno1 transfers to inno2.
|OK
|OK
|----
|inno1 calls PSTN-phone. PSTN-phone transfers to inno2.
|OK
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to inno2.
|OK
|OK
|----
|PSTN-phone calls inno1. PSTN-phone transfers to inno2.
|OK
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to other PSTN-phone-2.
|OK
|OK
|}

=== Blind Transfer ===

{| border="1"
!Tested feature
!Result
|----
|Call can be transferred
|OK
|----
|Held end hears dialling tone
|OK
|}

The following tests are made to test if call transfer is working.

{| border="1"
!Tested feature
!Voice Ok?
|----
|inno1 calls inno2. inno2 transfers to PSTN-phone.
|OK
|----
|inno1 calls PSTN-phone. inno1 transfers to inno2.
|OK
|----
|inno1 calls PSTN-phone. PSTN-phone transfers to inno2.
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to inno2.
|OK
|----
|PSTN-phone calls inno1. PSTN-phone transfers to inno2.
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to other PSTN-phone-2.
|OK
|}

=== CFU / CFB Transfer ===

{| border="1"
!Tested feature
!Result
|----
|'''Call can be forward'''
|'''OK'''
|----
|'''Held end hears dialling tone'''
|'''OK'''
|}

=== CFNR / Blind Transfer (alerting only)===

{| border="1"
!Tested feature
!Result
|----
|'''Call can be transferred or forward'''
|'''OK'''
|----
|'''Held end hears dialling tone'''
|'''OK'''
|}

The following tests are made to test if call transfer is working.

{| border="1"
!Tested feature
!Voice Ok?
|----
|inno1 calls inno2. inno2 transfers to PSTN-phone.
|OK
|----
|inno1 calls PSTN-phone. PSTN-phone transfers to inno2.
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to inno2.
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to other PSTN-phone-2.
|OK
|}

=== Broadcast Group & Waiting Queue ===

{| border="1"
!Tested feature
!Result
|----
|'''Caller can make a call to a Broadcast Group'''
|'''OK'''
|----
|'''Caller can make a call to a Waiting Queue'''
|'''OK'''
|----
|'''Announcement if nobody picks up the call'''
|'''OK'''
|}

== Configuration ==

===Firmware version===

All innovaphone devices use V11 build 11.3127 as firmware during test.

=== SIP - Trunk ===
Following configuration needs to be done in the SIP Gateway Interface settings:

* 1: Use "Gateway without Registration" as "Mode"
* 2: Enter the IP address of Sunrise SBC for "Remote Domain"
* 3: Enter the IP address of the innovaphone Gateway for "Local Domain"
* 4: Enter the IP address of Sunrise SBC for "Proxy"
* 5: Select G.711a as coder 20ms as Framsize and Exclusive
* 6: Disable "T.38", Enable Media-Relay" and No ICE"
* 7: Disable encryption
* 6: Use "Fixed AOR" in "From Header" and "CGPN in user part of URI" in "Identity Header"

[[Image:SunriseSIPProviderTestConfig1.png]]

=== Number Mapping ===
Following configuration needs to be done in the SIP Gateway Number Mappings:

* 1: Because Sunrise is using the full national number for incoming calls, you need to cut off the digits before an extension. In example, 04450199xx will be translated to xx.

[[Image:SunriseSIPProviderTestConfig2.png]]

=== Route Settings ===
A default Route Setup is used:

* 1: Force Enblock Setting is required for outgoing calls.

[[Image:SunriseSIPProviderTestConfig3.png]]

=== Fax ===
'''Sunrise does not support Fax communications with T.38.''' Because of this, T.38 can not be used.

If you want to use our Faxserver, you need to set T.38 to G.711 translation (Audio Fax support, available from V11). This works in a lot of cases where you have no problems with QoS.

Example to set T.38 to G.711 translation (Audio Fax support) on the Faxserver interface:

[[Image:SunriseSIPProviderTestConfig4.png]]

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

Howto:Sunrise Business voice - SIP Trunk - SIP Provider Compatibility Test

2015-07-03T11:36:13Z

Nfinzel: /* Summary */

'''Innovaphone Compatibility Test Report'''

== Summary ==

'''SIP Provider: Sunrise Business voice'''

The provider supports all mandatory innovaphone features and is therefore qualified as [[Howto:What_is_a_%22recommended_product%22%3F#SIP_Provider|recommended SIP Provider]].

That being said, the provider has achieved 86,34% of all possible test points (139 of 161). For more information on the test rating, please refer to [[Howto:SIP_Interop_Test_Description_v11#|Test Description V11 and later]]

'''Please Note, that some features are restricted or not supported by Sunrise'''
** The T.38 feature is not available
** Fax via G.711 (T.38 to G.711 / Audio Fax support) is supported by Sunrise and work in most scenarios.
* Only G.711a, G.711u is supported, in special cases G.729 is supported, no other codecs are supported
* Overlapped Sending is not supported
* NAT Detection is not supported
* Redundancy Mechanism are supported when using two Sunrise Gateways
* SIP over TCP and SIP over TLS is not supported
* Call using STP are not supported

'''Sunrise doesn't support "Reverse Media negotiation". Because of this, "Media-Relay" and an "Exclusive Coder Setting" must be configured.''' In contrast to a SIP trunk which does not need Media-Relay, the transport of all RTP packets across the gateway will result in a higher CPU load.

In order to use some Features like[[Howto:How_does_CLIP_no_screening_work | Clip no screening]], some [[Howto:Sunrise_-_SIP_Trunk_-_SIP_Provider_Compatibility_Test#Configuration|configuration]] must be done.

Supported Features:
* Direct Dial In
* DTMF
* CGPN can be suppressed
* CLIP No Screening
* Hold/Retrieve
* Blind Transfer

Supported Codecs:
* G.711a, G.711u and in special cases G.729 only

== Current test state ==

{{Template:Compat Status "in progress"}}










Testing of this product has been finalized July 2015.

== Testing Enviroment ==

[[Image:SunriseSIPProviderTestTopology1.png]]

This scenario describes a setup where the PBX and phones are in a private network.

Sunrise is providing an own Gateway ("SBC") which must be located in the customers private network. This Gateway has two connections:
* One connection to Sunrise
* One connection to the PBX
Because of this, the SIP Trunk does not connect directly to the internet, but to the Sunrise Gateway ("SBC").

The SIP trunk must be configured with "Media Relay", "exclusive G.711a" and "NO T.38".

[[Howto:Sunrise_Business_voice_-_SIP_Trunk_-_SIP_Provider_Compatibility_Test#Configuration|See configuration]]

== Test Results ==

For more information on the test procedure, please read the following wiki article: [[Howto:SIP_Interop_Test_Description_v11#|Test Description V11 and later]]. Bold lines in the test results indicate a KO-criteria.

(*1) In special cases G.729 is supported, must be booked and enabled at Sunrise

(*2) Fax via G.711 (T.38 to G.711 / Audio Fax support) is supported by Sunrise and work in most scenarios.

(*3) While Sunrise do not offer a second ip address on the same port as the gateway, Sunrise offers a dual homing solution involving two SBCs configured on one account.

=== Basic Call ===

{| border="1"
!Tested feature
!Result
|----
|'''call using g711a'''
|'''OK'''
|----
|'''call using g711u'''
|'''OK'''
|----
|call using g723
|NA
|----
|call using g729
|'''OK''' (*1)
|----
|call using g722
|NA
|----
|Overlapped sending
|NA
|----
|'''early media channel outgoing'''
|'''OK'''
|----
|Fax using T.38
|NA
|----
|T.38 Transcoding by the provider
|NA
|----
|Fax using G.711
|OK (*2)
|----
|Reverse Media Negotiation
|NOK
|----
|CGPN can be suppressed
|OK
|----
|CLIP no screening
|OK
|----
|'''Long time call possible(>30 min)'''
|'''OK'''
|----
|'''External Transfer'''
|'''OK'''
|----
|NAT Detection
|NA
|----
|Redundancy
|OK (*3)
|----
|SIP over TCP
|NA
|----
|'''Voice Quality OK?'''
|'''OK'''
|}

=== Direct Dial In ===

{| border="1"
!Tested feature
!Result
|----
|'''Inbound(Provider -> Innovaphone)'''
|'''OK'''
|----
|'''Outbound(Innovaphone -> Provider)'''
|'''OK'''
|----
|'''Loop In call(Innovaphone -> Provider -> Innovaphone)'''
|'''OK'''
|}

=== DTMF ===

{| border="1"
!Tested feature
!Result
|----
|'''DTMF tones sent correctly via RTP-events(RFC 2833)'''
|'''OK'''
|----
|DTMF tones sent correctly via SIP-Info
|OK
|----
|'''DTMF tones received correctly via RTP-events(RFC 2833)'''
|'''OK'''
|}

=== Hold/Retrieve ===

{| border="1"
!Tested feature
!Result
|----
|'''Call can be put on hold'''
|'''OK'''
|----
|Held end hears music on hold / announcement from PBX
|OK
|}

=== Transfer with consultation ===

{| border="1"
!Tested feature
!Result
|----
|'''Call can be transferred'''
|'''OK'''
|----
|Held end hears music on hold
|OK
|}

The following tests are made to test if call transfer is working.

{| border="1"
!Tested feature
!Voice Ok?
!MoH Ok?
|----
|inno1 calls inno2. inno2 transfers to PSTN-phone.
|OK
|OK
|----
|inno1 calls PSTN-phone. inno1 transfers to inno2.
|OK
|OK
|----
|inno1 calls PSTN-phone. PSTN-phone transfers to inno2.
|OK
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to inno2.
|OK
|OK
|----
|PSTN-phone calls inno1. PSTN-phone transfers to inno2.
|OK
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to other PSTN-phone-2.
|OK
|OK
|}

=== Transfer with consultation (alerting only) ===

{| border="1"
!Tested feature
!Result
|----
|'''Call can be transferred'''
|'''OK'''
|----
|Held end hears music on hold or dialling tone
|OK
|----
|'''Call returns to transferring device if the third'''
'''Endpoint is not available'''
|'''OK'''
|}

The following tests are made to test if call transfer is working.

{| border="1"
!Tested feature
!Voice Ok?
!MoH Ok?
|----
|inno1 calls inno2. inno2 transfers to PSTN-phone.
|OK
|OK
|----
|inno1 calls PSTN-phone. inno1 transfers to inno2.
|OK
|OK
|----
|inno1 calls PSTN-phone. PSTN-phone transfers to inno2.
|OK
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to inno2.
|OK
|OK
|----
|PSTN-phone calls inno1. PSTN-phone transfers to inno2.
|OK
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to other PSTN-phone-2.
|OK
|OK
|}

=== Blind Transfer ===

{| border="1"
!Tested feature
!Result
|----
|Call can be transferred
|OK
|----
|Held end hears dialling tone
|OK
|}

The following tests are made to test if call transfer is working.

{| border="1"
!Tested feature
!Voice Ok?
|----
|inno1 calls inno2. inno2 transfers to PSTN-phone.
|OK
|----
|inno1 calls PSTN-phone. inno1 transfers to inno2.
|OK
|----
|inno1 calls PSTN-phone. PSTN-phone transfers to inno2.
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to inno2.
|OK
|----
|PSTN-phone calls inno1. PSTN-phone transfers to inno2.
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to other PSTN-phone-2.
|OK
|}

=== CFU / CFB Transfer ===

{| border="1"
!Tested feature
!Result
|----
|'''Call can be forward'''
|'''OK'''
|----
|'''Held end hears dialling tone'''
|'''OK'''
|}

=== CFNR / Blind Transfer (alerting only)===

{| border="1"
!Tested feature
!Result
|----
|'''Call can be transferred or forward'''
|'''OK'''
|----
|'''Held end hears dialling tone'''
|'''OK'''
|}

The following tests are made to test if call transfer is working.

{| border="1"
!Tested feature
!Voice Ok?
|----
|inno1 calls inno2. inno2 transfers to PSTN-phone.
|OK
|----
|inno1 calls PSTN-phone. PSTN-phone transfers to inno2.
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to inno2.
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to other PSTN-phone-2.
|OK
|}

=== Broadcast Group & Waiting Queue ===

{| border="1"
!Tested feature
!Result
|----
|'''Caller can make a call to a Broadcast Group'''
|'''OK'''
|----
|'''Caller can make a call to a Waiting Queue'''
|'''OK'''
|----
|'''Announcement if nobody picks up the call'''
|'''OK'''
|}

== Configuration ==

===Firmware version===

All innovaphone devices use V11 build 11.3127 as firmware during test.

=== SIP - Trunk ===
Following configuration needs to be done in the SIP Gateway Interface settings:

* 1: Use "Gateway without Registration" as "Mode"
* 2: Enter the IP address of Sunrise SBC for "Remote Domain"
* 3: Enter the IP address of the innovaphone Gateway for "Local Domain"
* 4: Enter the IP address of Sunrise SBC for "Proxy"
* 5: Select G.711a as coder 20ms as Framsize and Exclusive
* 6: Disable "T.38", Enable Media-Relay" and No ICE"
* 7: Disable encryption
* 6: Use "Fixed AOR" in "From Header" and "CGPN in user part of URI" in "Identity Header"

[[Image:SunriseSIPProviderTestConfig1.png]]

=== Number Mapping ===
Following configuration needs to be done in the SIP Gateway Number Mappings:

* 1: Because Sunrise is using the full national number for incoming calls, you need to cut off the digits before an extension. In example, 04450199xx will be translated to xx.

[[Image:SunriseSIPProviderTestConfig2.png]]

=== Route Settings ===
A default Route Setup is used:

* 1: Force Enblock Setting is required for outgoing calls.

[[Image:SunriseSIPProviderTestConfig3.png]]

=== Fax ===
'''Sunrise does not support Fax communications with T.38.''' Because of this, T.38 can not be used.

If you want to use our Faxserver, you need to set T.38 to G.711 translation (Audio Fax support, available from V11). This works in a lot of cases where you have no problems with QoS.

Example to set T.38 to G.711 translation (Audio Fax support) on the Faxserver interface:

[[Image:SunriseSIPProviderTestConfig4.png]]

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

Howto:Sunrise Business voice - SIP Trunk - SIP Provider Compatibility Test

2015-07-03T11:33:13Z

Nfinzel: New page: '''Innovaphone Compatibility Test Report''' == Summary == '''SIP Provider: Sunrise Business voice''' The provider supports all mandatory innovaphone features and is therefore qualified ...

'''Innovaphone Compatibility Test Report'''

== Summary ==

'''SIP Provider: Sunrise Business voice'''

The provider supports all mandatory innovaphone features and is therefore qualified as [[Howto:What_is_a_%22recommended_product%22%3F#SIP_Provider|recommended SIP Provider]].

That being said, the provider has achieved 86,34% of all possible test points (139 of 161). For more information on the test rating, please refer to [[Howto:SIP_Interop_Test_Description_v11#|Test Description V11 and later]]

'''Please Note, that some features are restricted or not supported by Sunrise'''
** The T.38 feature is not available
** Fax via G.711 (T.38 to G.711 / Audio Fax support) is supported by Sunrise and work in most scenarios.
* Only G.711a, G.711u is supported, in special cases G.729 is supported, no other codecs are supported
* Overlapped Sending is not supported
* NAT Detection is not supported
* Redundancy Mechanism are supported when using two Sunrise Gateways
* SIP over TCP and SIP over TLS is not supported
* Call using STP are not supported

'''Sunrise doesn't support "Reverse Media negotiation". Because of this, "Media-Relay" and an "Exclusive Coder Setting" must be configured.''' In contrast to a SIP trunk which does not need Media-Relay, the transport of all RTP packets across the gateway will result in a higher CPU load.

In order to use some Features like[[Howto:How_does_CLIP_no_screening_work | Clip no screening]], some [[Howto:Swisscom_-_SIP_Trunk_-_SIP_Provider_Compatibility_Test#Configuration|configuration]] must be done.

Supported Features:
* Direct Dial In
* DTMF
* CGPN can be suppressed
* CLIP No Screening
* Hold/Retrieve
* Blind Transfer

Supported Codecs:
* G.711a, G.711u and in special cases G.729 only

== Current test state ==

{{Template:Compat Status "in progress"}}










Testing of this product has been finalized July 2015.

== Testing Enviroment ==

[[Image:SunriseSIPProviderTestTopology1.png]]

This scenario describes a setup where the PBX and phones are in a private network.

Sunrise is providing an own Gateway ("SBC") which must be located in the customers private network. This Gateway has two connections:
* One connection to Sunrise
* One connection to the PBX
Because of this, the SIP Trunk does not connect directly to the internet, but to the Sunrise Gateway ("SBC").

The SIP trunk must be configured with "Media Relay", "exclusive G.711a" and "NO T.38".

[[Howto:Sunrise_Business_voice_-_SIP_Trunk_-_SIP_Provider_Compatibility_Test#Configuration|See configuration]]

== Test Results ==

For more information on the test procedure, please read the following wiki article: [[Howto:SIP_Interop_Test_Description_v11#|Test Description V11 and later]]. Bold lines in the test results indicate a KO-criteria.

(*1) In special cases G.729 is supported, must be booked and enabled at Sunrise

(*2) Fax via G.711 (T.38 to G.711 / Audio Fax support) is supported by Sunrise and work in most scenarios.

(*3) While Sunrise do not offer a second ip address on the same port as the gateway, Sunrise offers a dual homing solution involving two SBCs configured on one account.

=== Basic Call ===

{| border="1"
!Tested feature
!Result
|----
|'''call using g711a'''
|'''OK'''
|----
|'''call using g711u'''
|'''OK'''
|----
|call using g723
|NA
|----
|call using g729
|'''OK''' (*1)
|----
|call using g722
|NA
|----
|Overlapped sending
|NA
|----
|'''early media channel outgoing'''
|'''OK'''
|----
|Fax using T.38
|NA
|----
|T.38 Transcoding by the provider
|NA
|----
|Fax using G.711
|OK (*2)
|----
|Reverse Media Negotiation
|NOK
|----
|CGPN can be suppressed
|OK
|----
|CLIP no screening
|OK
|----
|'''Long time call possible(>30 min)'''
|'''OK'''
|----
|'''External Transfer'''
|'''OK'''
|----
|NAT Detection
|NA
|----
|Redundancy
|OK (*3)
|----
|SIP over TCP
|NA
|----
|'''Voice Quality OK?'''
|'''OK'''
|}

=== Direct Dial In ===

{| border="1"
!Tested feature
!Result
|----
|'''Inbound(Provider -> Innovaphone)'''
|'''OK'''
|----
|'''Outbound(Innovaphone -> Provider)'''
|'''OK'''
|----
|'''Loop In call(Innovaphone -> Provider -> Innovaphone)'''
|'''OK'''
|}

=== DTMF ===

{| border="1"
!Tested feature
!Result
|----
|'''DTMF tones sent correctly via RTP-events(RFC 2833)'''
|'''OK'''
|----
|DTMF tones sent correctly via SIP-Info
|OK
|----
|'''DTMF tones received correctly via RTP-events(RFC 2833)'''
|'''OK'''
|}

=== Hold/Retrieve ===

{| border="1"
!Tested feature
!Result
|----
|'''Call can be put on hold'''
|'''OK'''
|----
|Held end hears music on hold / announcement from PBX
|OK
|}

=== Transfer with consultation ===

{| border="1"
!Tested feature
!Result
|----
|'''Call can be transferred'''
|'''OK'''
|----
|Held end hears music on hold
|OK
|}

The following tests are made to test if call transfer is working.

{| border="1"
!Tested feature
!Voice Ok?
!MoH Ok?
|----
|inno1 calls inno2. inno2 transfers to PSTN-phone.
|OK
|OK
|----
|inno1 calls PSTN-phone. inno1 transfers to inno2.
|OK
|OK
|----
|inno1 calls PSTN-phone. PSTN-phone transfers to inno2.
|OK
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to inno2.
|OK
|OK
|----
|PSTN-phone calls inno1. PSTN-phone transfers to inno2.
|OK
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to other PSTN-phone-2.
|OK
|OK
|}

=== Transfer with consultation (alerting only) ===

{| border="1"
!Tested feature
!Result
|----
|'''Call can be transferred'''
|'''OK'''
|----
|Held end hears music on hold or dialling tone
|OK
|----
|'''Call returns to transferring device if the third'''
'''Endpoint is not available'''
|'''OK'''
|}

The following tests are made to test if call transfer is working.

{| border="1"
!Tested feature
!Voice Ok?
!MoH Ok?
|----
|inno1 calls inno2. inno2 transfers to PSTN-phone.
|OK
|OK
|----
|inno1 calls PSTN-phone. inno1 transfers to inno2.
|OK
|OK
|----
|inno1 calls PSTN-phone. PSTN-phone transfers to inno2.
|OK
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to inno2.
|OK
|OK
|----
|PSTN-phone calls inno1. PSTN-phone transfers to inno2.
|OK
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to other PSTN-phone-2.
|OK
|OK
|}

=== Blind Transfer ===

{| border="1"
!Tested feature
!Result
|----
|Call can be transferred
|OK
|----
|Held end hears dialling tone
|OK
|}

The following tests are made to test if call transfer is working.

{| border="1"
!Tested feature
!Voice Ok?
|----
|inno1 calls inno2. inno2 transfers to PSTN-phone.
|OK
|----
|inno1 calls PSTN-phone. inno1 transfers to inno2.
|OK
|----
|inno1 calls PSTN-phone. PSTN-phone transfers to inno2.
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to inno2.
|OK
|----
|PSTN-phone calls inno1. PSTN-phone transfers to inno2.
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to other PSTN-phone-2.
|OK
|}

=== CFU / CFB Transfer ===

{| border="1"
!Tested feature
!Result
|----
|'''Call can be forward'''
|'''OK'''
|----
|'''Held end hears dialling tone'''
|'''OK'''
|}

=== CFNR / Blind Transfer (alerting only)===

{| border="1"
!Tested feature
!Result
|----
|'''Call can be transferred or forward'''
|'''OK'''
|----
|'''Held end hears dialling tone'''
|'''OK'''
|}

The following tests are made to test if call transfer is working.

{| border="1"
!Tested feature
!Voice Ok?
|----
|inno1 calls inno2. inno2 transfers to PSTN-phone.
|OK
|----
|inno1 calls PSTN-phone. PSTN-phone transfers to inno2.
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to inno2.
|OK
|----
|PSTN-phone calls inno1. inno1 transfers to other PSTN-phone-2.
|OK
|}

=== Broadcast Group & Waiting Queue ===

{| border="1"
!Tested feature
!Result
|----
|'''Caller can make a call to a Broadcast Group'''
|'''OK'''
|----
|'''Caller can make a call to a Waiting Queue'''
|'''OK'''
|----
|'''Announcement if nobody picks up the call'''
|'''OK'''
|}

== Configuration ==

===Firmware version===

All innovaphone devices use V11 build 11.3127 as firmware during test.

=== SIP - Trunk ===
Following configuration needs to be done in the SIP Gateway Interface settings:

* 1: Use "Gateway without Registration" as "Mode"
* 2: Enter the IP address of Sunrise SBC for "Remote Domain"
* 3: Enter the IP address of the innovaphone Gateway for "Local Domain"
* 4: Enter the IP address of Sunrise SBC for "Proxy"
* 5: Select G.711a as coder 20ms as Framsize and Exclusive
* 6: Disable "T.38", Enable Media-Relay" and No ICE"
* 7: Disable encryption
* 6: Use "Fixed AOR" in "From Header" and "CGPN in user part of URI" in "Identity Header"

[[Image:SunriseSIPProviderTestConfig1.png]]

=== Number Mapping ===
Following configuration needs to be done in the SIP Gateway Number Mappings:

* 1: Because Sunrise is using the full national number for incoming calls, you need to cut off the digits before an extension. In example, 04450199xx will be translated to xx.

[[Image:SunriseSIPProviderTestConfig2.png]]

=== Route Settings ===
A default Route Setup is used:

* 1: Force Enblock Setting is required for outgoing calls.

[[Image:SunriseSIPProviderTestConfig3.png]]

=== Fax ===
'''Sunrise does not support Fax communications with T.38.''' Because of this, T.38 can not be used.

If you want to use our Faxserver, you need to set T.38 to G.711 translation (Audio Fax support, available from V11). This works in a lot of cases where you have no problems with QoS.

Example to set T.38 to G.711 translation (Audio Fax support) on the Faxserver interface:

[[Image:SunriseSIPProviderTestConfig4.png]]

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

File:SunriseSIPProviderTestConfig4.png

2015-07-03T11:32:02Z

Nfinzel:

File:SunriseSIPProviderTestConfig3.png

2015-07-03T11:31:48Z

Nfinzel:

File:SunriseSIPProviderTestConfig2.png

2015-07-03T11:31:35Z

Nfinzel:

File:SunriseSIPProviderTestConfig1.png

2015-07-03T11:31:09Z

Nfinzel:

Howto:Sunrise - SIP Trunk - SIP Provider Compatibility Test

2015-07-03T11:23:37Z

Nfinzel:

[[Howto:Sunrise_Business_voice_-_SIP_Trunk_-_SIP_Provider_Compatibility_Test#Configuration|See configuration]]

Howto:Sunrise - SIP Trunk - SIP Provider Compatibility Test

2015-07-03T11:22:36Z

Nfinzel: New page: See configuration

[[Howto:Sunrise_-_SIP_Trunk_-_SIP_Provider_Compatibility_Test#Configuration|See configuration]]

File:SunriseSIPProviderTestTopology1.png

2015-07-03T11:18:32Z

Nfinzel:

Howto:Looping in a innovaphone Gateway

2015-05-12T13:28:22Z

Nfinzel: /* Applies To */

Please note: this article describes a slightly different configuration than the one created by the box wizard for IP6000 and IP800.

==Summary==

This article will describe the essentials of a simple loop in scenario. This article will not describe how to configure your BRI/PRI interfaces. Because the CGPN mappings differ from case to case, we will assume that our trunk number is +49 (5085) 970.

In our test scenario we will use a IP6000, which is looped in between an old PBX and the trunk line to the ISDN provider. To keep it simple, the old PBX will have only one PRI line to its ISDN provider. We assume that ISDN providers behavior is like DT AG or Arcor. The configuration of CGPN/CDPN mappings may vary significant from described in case your have other ISDN provider. For more information about specific configuration for other providers please check related articles.

Our goal is to correctly loop in the innovaphone PBX, without making changes at the old PBX. Also we want to add some new IP - phones, which are registered and connected to the IP6000.

The nice thing is,when we want to replace the old Pbx extensions with new Ip phones - you only need to make a external call diversion to your own extension , example the Old Pbx extension is 10 - we make an call diversion on this old Phone( extension 10) to 05085 970 10 - so if any Old Pbx User dials the extension 10 the call will be forwarded to the Isdn and the looped in innovaphone Pbx will catch the call and route it to the new Ip phone extenstion 10.

==Applies To==
This information applies to

* IP6000
* IP3000
* IP810
* IP800
* IP305 *

* the Gateway has no hardware relay. This is why it has no hardware fallback mechanism, in case that the Gateway is cut from power.
Also this type of gateway is not able, to use the 'Enable PCM' option for physically relaying ISDN - Data channels between two
ISDN(BRI/PRI) interfaces.

==Configuration==

===PBX - Objects===

I assume that the ISDN interfaces of the IP6000 are configured correctly. We will use the PRI1 ISDN interface to connect to the ISDN provider, while the PRI2 interface will be used to connect to the old PBX.

First we will create the PBX objects. The Trunk line Object is needed to get the calls to the ISDN provider. We also need an "Extern" Gateway object. This Gateway is used to get calls to unknown PBX objects to the "old PBX". Afterwards the user objects are configured. For our example we will configure only one user, which uses an ip phone and is registered at the IP6000.

[[Image:Looping_in_a_innovaphone_Gateway_2.PNG]]

[[Image:Looping_in_a_innovaphone_Gateway_1.PNG]]

[[Image:Looping_in_a_innovaphone_Gateway_3.PNG]]

After creating this objects, it is important to change the General PBX Settings, so that calls to unknown numbers get routed to the External Gateway.

[[Image:Looping_in_a_innovaphone_Gateway_4.PNG]]

After having configured the PBX settings, we will configure the Gateways.

===Interface mappings===

Like described before, we will use only the PRI1 and the PRI2 interface of the IP6000. The PRI1 interface is connected to the ISDN provider, the PRI2 interface to the old PBX. If you need another PRI line, then use also the PRI3 interface to connect to the provider and the PRI4 interface to the old PBX. It is important to keep this sequence of interfaces (PRI1,PRI3 to provider & PRI2,PRI4 to old PBX) in case that the IP6000 is disconnected from its power supply. A hardware relay in the IP6000 will then transfer the ISDN calls from PRI1<->PRI2 and PRI3<->PRI4 automatically, even while the IP6000 is without power.

This described hardware releay is also in the IP3000 and IP800 but not in the IP305 in case of powering off the Gateway.

Now the PRI1 interfaces gets registered at the PBX trunkline object and the PRI2 interface is registered at the EXTERN Gateway. Another important setting is to enable the "Enable PCM" checkbox. This will preserve DSP channels. The PBX will recognize if a call has just to be routed from PRI1 to PRI2 and will not use DSP to convert the Media Channels.

Also for Modem support connected at the Old Pbx the PCM feature will help - the data will not be converted into IP instead handled directly over the ISDN PCM bus - that avoids Modem conenction problems via IP.

By activating the ''Enable T.38'' Flag on the interface, the T.38 protocoll is used for transporting Fax over IP. If it is planned to connect a fax machine to the IP-PBX, it is mandatory to activate this flag.

[[Image:Looping_in_a_innovaphone_Gateway_5.PNG]]

[[Image:Looping_in_a_innovaphone_Gateway_6.PNG]]

At this point we will have to do some mappings at the ISDN interfaces. The main goal of the interface mappings is to correctly convert the international & national ISDN number flags. The second goal is to uniform the incoming CDPN, so the PBX routing can be simplified to handle only one kind of number format.

Administration/Gateway/Interface PRI1

[[Image:Looping_in_a_innovaphone_Gateway_8.PNG]]

At the PRI1 interface we can manipulate the incoming and outgoing patry numbers(CGPN & CDPN).
*for incoming calls (ISDN->PBX)
**CDPN:
***we chop away the international or national prefixes. By this method, all calls that will reach the PBX will have a CDPN in local area format.
**CGPN:
***we replace the international & national ISDN number flags with dialable numbers(i.e. I->00 and n->0)

*for outgoing calls (PBX->ISDN)
**CGPN & CDPN:
***we add depending on the calling number the appropriate ISDN types(international,national,subscriber)
***it is also important to use the numbering plan options to mark outgoing calls as ISDN type. If they are not marked as such, it is possible that the ISDN provider will not accept outgoing CGPN.

Administration/Gateway/Interface PRI2

[[Image:Looping_in_a_innovaphone_Gateway_9.PNG]]

On the PRI2 interface (our connection to the old PBX)we will do the following mappings:
*for incoming calls (oldPBX->IP6000)
**CGPN:
***we again chop away the international or national prefixes. In addition to that we must consider the possibility of a call beeing rerouted in the old PBX. In this scenario the CGPN will not contain the local trunk number, so that we only need to change the international/national flags.
**CDPN:
***At this point, it is only required to replace the international & national ISDN number flags with dialable numbers

*for outgoing calls (IP6000->oldPBX)
**CGPN & CDPN:
***we add depending on the calling number the appropriate ISDN types(international,national,subscriber)

We are almost finished. Now we have to configure the routes between the interfaces.

===Routes===

[[Image:Looping_in_a_innovaphone_Gateway_7.PNG]]

Since the interface mappings are only used for the correct conversion and uniformization of incoming and outgoing numbers, the whole looping logic is contained by the Routes. Thats why we will go through every route separately. Pease note that most of the routes have CDPN aswell as CGPN mapings. For improving the compatibility with different ISDN provider and PBX manufacturers, we will enable on all routes the interworking flag.

====Route1(From Carrier to PBX)====
This route relays calls into the PBX. Since we already uniformized the CDPN to a subscriber format, we only need to remove the subscriber prefix. The remaining part of the CDPN is the phone extension.

====Route2(From PBX to Carrier)====
Under normal circumstances it suffices to transmit a CGPN in subscriber format to the ISDN provider. He will then correctly format the CGPN depending on the CDPN.(e.g. when calling an international number the provider will change the CGPN form '970'123 to '00495085970'123).
The problem for outgoing calls(to the provider) is when the customer wants to use the CLIP - no screening feature. When this feature is enabled by the provider, he will no longer check the CGPN. (e.g. when calling an international number the provider will not change the CGPN. The called international phone will not be able to call back, due to uncorrect CGPN). This is the reason why we will handle outgoing international calls separately in the routes.
*Route2-Branch1(From PBX to Carrier - international call):
If the CDPN is starting with '00' the outgoing call target is international. We now have to check the existing CGPN format. To understand why we use 4 different mappings on this route, you must consider the following lines.
A call from the PSTN calls a phone at the IP6000/oldPBX. However this phone is to forward the calls to a recipient in the PSTN(e.g. mobile phone). Since the call originally entered the PBX using our Trunkline - PBX object, a leading '0' was prepended to the CGPN.
We now have 4 possibilites:
#If the CGPN is starting with '000' it must be an international number. In this case we will only cut away the leading '0' and be done with the mapping.
#If the CGPN is starting with '00' it must be an national number. Since this is a call to a international number, we must get the CGPN in internalional format.
#If the CGPN is starting with '0' it must be an local number. Again, because this is a call to a international number, we must get the CGPN in internalional format.
#Finally we also have the possibility that the call origins from a phone registered at the IP6000 or at the oldPBX. In this case we will also need to use an international CGPN format.
*Route2-Branch2(From PBX to Carrier - national call):
The logic for this route is analog to Route2-Branch1.

====Route3(From OldPBX to IP6000)====
This route will handle calls from the oldPBX to the IP6000. We have different branches, to separate calls to a user registered at the IP6000(branch1-3) and phones in the PSTN(branch4). When looking at the routes in Branch 1-3, remember that we didn't cut the trunk number at the interface mappings(because of overlap dialing). Therefor we must now handle separately different CDPN formats(international,national,local).
*Route3-Branch1(From Old PBX to PBX - CDPN in international format):
This route handles calls to users registered at the IP6000. We cut away the trunk number and forward the call to the PBX. However we must consider two possibilities for the CGPN. If the caller is a user from the oldPBX, we cut away the local prefix(CGPNhas been uniformized at the interface mapping). There is also the possibility that the original caller is a user in the PSTN. In this case the CGPN, will be a number in the PSTN. In this case we must prepend a leading '0'. In Route2 we will then eventually use the leading '0', to handle the number mapping.
*Route3-Branch2(From Old PBX to PBX - CDPN in national format):
The logic for this route is analog to Route3-Branch1.
*Route3-Branch3(From Old PBX to PBX - CDPN in local format):
The logic for this route is analog to Route3-Branch1.
*Route3-Branch4(From Old PBX to PBX - CDPN differs from trunk number)
Since we already handled calls to users in the PBX, we must no think about users in the PSTN. By prepending a leading '0' to the CDPN, the call will be forwarded to the Trunk Line Object in the PBX. Using the Trunk Line Object it will then be forwarded to ISDN provider. Again, we must handle both possibilities for the CGPN. The logic for the CGPN mapping is equal to the one used in the former Route3 branches.
====Route4(From PBX to Old PBX)====
This route handles calls to the oldPBX. We will forward the calls to the old PBX with a local area prefix. Therefore we prepend the local area prefix. At the CGPN mappings, we again must consider 2 possibliites. If the calling party is a number in the PSTN, we must chop away the leading '0'. This '0' was prepended, because the call entered the PBX using the Trunk Line Object. In case that the CGPN does not start with '0', the CGPN must be an extension/phone registered at the IP6000. In this case we will prepend the local area prefix.

==Special Case - provider sends only extension number as CDPN==

Some ISDN providers already cut away the trunk number, before sending it to the PBX. In this case the CDPN would contain only the phone extension(using a Unknown number format). We must also consider that the oldPBX will also expect incoming CDPN in this format.
To handle this situation, our interface mappings on the PRI interfaces must be adjusted. Since we don't want to change the routes, we must stay with our uniform number format. The incoming CDPN will be transformed in a local area number.(e.g. 200->'970'200)

Let's start with the PRI1 interface.

[[Image:Looping_in_a_innovaphone_Gateway_10.PNG]]

On the PRI1 interface we will adjust the handling of incoming numbers with unknown format. Since in some countrys (like Italy) it is also common that every CDPN/CGPN is sent in unknow number format, we will first filter out incoming CDPN/CGPN starting with '0'. This is certainly not a phone extension number, so we will just forward it without further modifying the number. In case that the number does not start with '0', we assume that the provider sends us an abbreviated number(phone extension). We will then prepend our local area prefix to this extension, since our routes will handle only number in this local area format(i.e. starting with 970) correctly.

Now let's have a look at the PRI2 mappings.

[[Image:Looping_in_a_innovaphone_Gateway_11.PNG]]

On this interface we must consider that incoming calls will also have an abbreviated CGPN/CDPN format. In this case we will make similar adjustments to the PRI1 interface mappings. For outgoing calls we must now cut away the local area prefix of the CDPN, since the oldPBX is expecting the CDPN formatted like a phone extension.

==Partial Rerouting==

Partial Rerouting (PR) is an ISDN supplementary service.

It realizes a call diversion by the replacement of a call connection from a user-A to a user-B by a call connection from user-A to user-C.

User-A and User-C reside in the PSTN. User-B resides within an innovaphone PBX. User-B activated a diversion (CFU, CFNR) towards user-C.

If the Isdn provider supports this feature we maybe need to add configuration on the routes. please read therefore related articles below.



==Related Articles==

[[Media:Loopin matrix.zip|Testmatrix for Looping In Szenarios]]

[[Howto:CGPN and CDPN Mappings on ISDN Trunk from EWE TEL]]

[[Howto:How to Configure EDSS1 Partial Rerouting]]

[[Support:SR2 Upgrade Issue: Partial Rerouting Over BRI Interfaces]]



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

Reference10:Concept Voice Recording 2014

2015-05-11T10:08:39Z

Nfinzel: /* Recording with the IP-Phone */

== Introduction ==

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 records are stored in a first step on the Conpact flash or webdav server and processed then form the recorder tool.

Voice recording can be done on a logical or fiscal gateway (BRI, GW, SIP etc.), and therefore all kind of audio traffic can be recorded. Technically spoken a gateway is doing media relay and writes the audio data to the webdav or CF.

The second way to record is recording directly from the innovaphone IP-Phone. In this case the phone itself writes the audio data to the CF or webdav server.

See the “Scenarios” for further details.

The solution requires an innovaphone PBX, the reporting tool 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.

IMPORTANT: All users that should be recorded need the REPORTING! We recommend reporting for all user, see chapter “Requirements” for further details.

== Requirements ==

===PBX===
You require a PBX version 10 or higher, version 11 is recommended.

===Reporting===

The recording feature requires the innovaphone Reporting. Required Version 10, Build 10043, Version 11 recommended.

At least any user that should be recorded must have the reporting. If user will generate pcap files (do a recording) it is recommended that also those users should have a recording; generally we recommend that all users in the PXN should have the recording on. Here is why: if the recorder found a pcap file (an audio file) he will “ask” the reporting about the involved users. If the reporting has no information (because those users have no reporting) the answer will be a “not found”. Therefore the recorder will try later on more times to found the record in the recording, all that will slow down the entire system.

=== Recorder ===

This document describes Build 10089. Please note that from build 10084 on no more drive mapping is done and 10089 supports https.

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.
The stores voce data is not PCM but a G.711 format in a wave container. PCM require much more disk space and is not used for storing. The audio files can also be encrypted. Encryption would double the required disk space. The recorded conversation is a stereo file where the external caller is on the left channel whiles the internal one in the right channel. It is possible down mix the conversation to mono; this would save about 50%. It is also possible compress the audio data to mp3.

The following table shows the required disk space for one minute of conversation:

[[Image:RecSetup07.png]]

Example: 500GB Hard disk, mp3 compression without encryption -> 1.389 days = 3,8 years of conversation

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 11 innovaphone PBX and a Version 11 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.

Remember that the CF is a relative slow drive, you will note this if you copy a file from the CF to the local HD of your PC. Exact this file copy is one of the task of the recorder, even a critical one (so not a good idea do anything else in between). The result is that the copy of a huge file (a long conversation) or many files will virtually froze the recorder software. In reality the recorder is just hanging around and waits that the file copy is finally done. So a recording on an external webdav server will solve this, but the CF has the nice flair working even if all PC’s are down. Take your choices and live with them.

Require Framework 4.5.

=== Codecs ===
Recording can only be done in G.711 or G.729. Calls with different codes (e.g. G.722) will still be recorded, but no wave files will be converted!

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

In theory it should work on any CPU, the Player was tested under Win7 32BIT, Win7 64Bit and Win8 64Bit.

===License===

The license model is based on user, so for each user to record a license is required.

The current implementation allows a recording of objects of type user or executive. Recordings on other objects will be discarded.

So in short: Per recorded user or executive object you need to have
* one recording license
* one reporting license

In start-up the recorder will read out the number of recording license in the PBX. After that the recorder will read out all users and check if a user is in the recording group (defined in the recorder setup). If a user with that group is found one license is counted down. If there are no more license but user in group detected they will be skipped. The recorder shows how many license where detected in the PBX and how many user are in the recording group. If there are more users than licenses a warning is show.

Remember that just users in the recorder user table are recorded; all other records are automatic deleted! This can be usefully if for example for internal reasons not just the user to record passes through the recording gateway but also others; not being in the group the records will be destroyed. But of course this will cause senseless PBX CPU workload because a recording anyway is done, just the recorder will delete after the files.

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

== Feature list ==

=== General ===

• Using an innovaphone IP-Phone set immediately after call end the recording can be listened using the phone. One feature key stroke and the conversation is reproduced and repeated endless (auto replay). This call can also be transferred or put in a 3 party conference (immediate sharing)

• Online Help and tooltips for application and setup

• Setup password protected, setup files are encrypted

• Recorder in Demo Mode (20 minutes) , Player for free

• Many recorder in one system and unlimited number of players

=== Recorder ===

• Recording of any type of calls direction

• Recording of calls from any device: IP-Phones (innovaphone and 3rt Party), analogue phones, GSM (mobility), IP-DECT

• Recording of calls from/to legacy PBX (smooth migration)

• Recording can be done in a logical gateway or direct from a innovaphone phone set

• Recording of encrypted calls

• Standard und thread call recording. If thread call recording is on after a settable time period (for example 5 minutes) a call will be automatically deleted. If the user calls inside the time period a code the last call will be saved. This marking to keep the recorded call can be done from any type of phone. If the phone is a innovaphone IP Phone the marking can be done also during conversation

• Storage of all relevant data including the time to answer for each call

• Detail protocol of each call, documentation of the entire call flow, not just the recording period but even previous and following one. Detail report on all call situations, transfer, call forwarding, pick-up, group call, conference etc. Also calls in waiting queues or announcements are reported with second accuracy

• Encrypted protocol data

• Display number of channels in recording with start timestamp

• Error and Event log files

• Email alert in case of master alarm

• Automatic backup (copy to mass storage archive)

• Automatic delete of records older than 2-99 month (not on archives)

• Recordings are saved as wave files, can be reproduced with any player

• Wave data integrity supervision

• File name contains primary data (Timestamp, Caller and called, direction, time to answer, UID)

• Counter of recorded conversations

• Data Link to player, remote control of the recorder from player

• Interface to external applications, via TCP or URL, recorder provides data for later retrieving. Player can be controlled sending commands to the recorder (3rd party)

• Mark record during a conversation on the IP-Phone (build 1077)

• Https from Build 10087 on

• Salve sites from Build 10089 on

=== Player ===

• Integrity of the recorded wave files are recognized and displayed

• Agent note, a Player displays automatically agent notes and can add text notes to each call

• Integration with iQM server, display of missed calls, possibility to recall immediately

• Naming of Players

• Month and Day filter

• Filter for internal and external number with wildcards

• Filter for incoming and outgoing calls

• View of oldest or newest call on top

• SOS mode can be switched on/off with just one click. If on all unnecessary key are hide, the newest calls are displayed on top of the call list and filters are switched off

• Selection of calls, one single call, more single selected calls, from to, all

• Online search and display, can be switched off

• Copy, move and delete of calls

• Move and delete operations are logged in centralized manipulation log

• Permissions

• Multiple selected calls can are transferred automatically in a playlist and can be reproduced

• Display record size

• Display number of records in playlist and actual play

• Jump forward and backward in playlist

• Jump to next/previous title in search result list if playlist contains just one record

• Marc record in playlist, select actual record and clear all others

• Play one title after the other in playlist

• Play a beep if record change in playlist (loop playlist)

• Repeat play (loop record), up to 4 positions, stored automatically

• Repeat play of all stored memory positions

• Display internal and external number with name resolution

• Display timestamp, time to answer an call ID

• Display System and Player status

• Display if local remote control interface is on

• Display of play was forced be recorder remote control

• Keys for Stop, Play, Fast Forwarding, Rewind, Pause and Eject

• Display duration record

• Display elapsed time or count down, switchable

• Original time elapsing display

• Progress bar adjustable, direct jump to selected position, drag and drop

• Start and Stop position can be marked an played in loop (selection loop)

• Volume control with audio meter and peek indication

• Delta level Indication (L-R and R-L meter)

• Overflow level audio meter

• Enhanced sensitivity for audio meter

• Attenuation left and right cannel adjustable

• Audio setup can be stored and recalled

• Audio level at maximum

• Levels are stored and set on restart

• Level meter with peek indicator for left and right cannel

• Mute

• Large additional display with call details

• Automatic decryption if files are copied

• Player can be limited to display just calls of one extension

• Communication with recorder, display of link status, last master alarm and cannels in recording

• Reset recorder from player

• Search an play on backup directories

• Operate as Media player, reproduction of audio format wav, mp3, wmp and video format avi, wmv, mp4 and mpg

• 1rst and 3rd party remote control

• Document security, manipulation is detected and displayed

• Browse last played records (build 1071)

• Browse marked records on this player (build 1071)

• Browse marked records in a system wide available directory (build 1071)

• Mark records on player and for system wide access (build 1071)

• Copy records marked in a player to the system wide available directory (build 1071)

• Write a central log for all player listening’s (build 1071)

• Work over hhtp connections (build 1074)

• Limit view to a list of extensions (build 1077)

== Scenarios ==

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 on a central point ===

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 or G729 on a logical gateway as endpoint. If you want record internal calls in this way calls must always transit a logical gateway (with the media relay flag on).

=== Recording with the IP-Phone ===

Recording can be done also directly from the innovaphone IP-Phone.
If switched on all calls from and to this phone are recorded, there are no recording rules. Calls could be stored in different files, because a new call means also a new file. If for example a phone put on hold a conversations and establish a second call this second call will be stored a an separate file.

Doing voice recording using the IP-Phone or using a Gateway has advantages and disadvantages; it depends on your point of view and the scenario.

Here some issues to remember:

Recording on a gateway is like the old “ISDN Recording”: anything passing that interface is recorded. That has the advantage that any type of endpoint (IP, 3rt party, Dect, analog etc.) will be recorded. The disadvantage is that internal calls are not recorded. Also the CPU load of the PBX will rise while recording with an IP-Phone has nearly no influence.

Recording directly from the Phone has the limitation that just innovaphone IP-Phone are able to doing that. Only innovaphone IP-Phones IP2x2, IP111 and IP241 can performing Voice Recording directly.
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).

In the V11r1 IP recording on the phone can just switched on or off in the setup, not from the user. In V11r2 recording can switched on and off by the user (similar to the 3party version).

Note: The recording described here does not require a phone 3 party conference; therefore a 3party conference is possible on the phone while recording is running.

== Recording Modes ==
=== Standard Recording ===

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

Note: A recorder canoperate just in one mode (for example "Standard"). Mixed scenario are possible but require two or more recorders, the setup in this case has to be done very carefully.

=== 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 sub-directory TCR in your PCAP recording directory and copy the xml in, create a VM-Object in the PBX and insert those parameters in the recorder setup (TCR panel). Example: Your PCAp directory is http://172.16.88.98/DRIVE/CF0/REC, therefore the directory create is is http://172.16.88.98/DRIVE/CF0/REC/TCR. 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.

=== Random recording ===
The recorder can work in this mode also as an alternative to the Standard- or Threat call recording. Random recording will record just a sample of calls on normal Agents (User), typically for quality check purposes.

The system allows record just each x call where x can be set in the setup. The system can even record just each y call for an agent. Only “to recording” calls are counted, not calls in general.

Example: “Record in System just each 3. Call”’: the system will store one record and then skip the following 2 one.

Example: “Record for a Gent just each 2. Call”: for each agent one call will be recorded and one not.

Both setups can be set isolated, but combined (3rd in system and 2nd for a agent) the system will first skip 2 calls and then for the specific agent skip each 2nd one.

Calls typically are not foreseeable especially if they are more agent involved and therefore it is for a single agent a “random” recording.

This feature requires build 1071 or higher.

=== Manual/Transparent/Optional recording ===

V11r2 (in the Phone) is required.

If the recording is done using a innovaphone IP Phone there are 3 recording modes possible:

- Manual: the user switch recording on/off using a Feature key

- Transparent: recording is always on

- Optional: recording is on by default but the user can switch it off using a feature key

The manual and optional mode is widely used because the operator can switch on and off recording during a conversation. For example if the customer want to buy the operator starts recording and give the advice that from now on the recording is on (by the way: that can be played also automatically modifying the last call recording xml). Switching off recording is usefully also if for example during a conversation a secret info (like a password) is stated and should not be recorded ad all.

The Recording link (url) to the Webdav or CF is defined in the user setup:

[[Image:RecSetup08.png]]

The mode is selected in the "recording" section:

[[Image:RecSetup09.png]]

Note: The recording described here does NOT require a phone 3 party conference; therefore a 3party conference is possible on the phone while recording is running.

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

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

(*) = Option

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.

== Installation Step 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 course, 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/System_Setup#Gateway_Setup . If you want to do a test with internal phones you have to assure that in call 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 course 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. Start the application and open the setup.

== Installation ==

While the Recorder works “hidden” for the user, the Player has a huge user interface. The Player is typically installed on one or more PC of users. Therefore for the Player more effort to design a foolproof interface was done. The Player description is available, 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 is even encrypt.

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.

=== Date ===

As most application also the recorder requires a correct date and time. But also the PBX Date and time must be correct and the same as the one on the recording PC.

Basically obviously, writing a file all file data should be correct, and also the CDR ticket data should.

So verify that both, PBX and PC have always a correct and synchronized date and time.

== Voice Recorder operation ==

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

[[Image:RecE111B1.png]]

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

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

*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:RecE111B2.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.

The following picture shows two alarms, Reporting (because there where files without CDR records) and Software (because there was a license overflow).

[[Image:RecXX.png]]

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

Basically calls that should not be recorded should not be recorded even on the CF, this is desirable, but not always feasible.

In normal operations the recorder is connected to the PBX with a SOAP link and can so detect when a call is finished and the party involved. If there is a PCAP file and a SOAP connection fine, because in the very first step anything is clear and the recorder can decide to save or to just delete the PCAP file. But there is also the possibility that the recorder starts up later and “found” PCAP files stored in the meantime. In this case there could be or even not any SOAP information, if the call terminated before the recorder starts there will no SOAP info. Therefore if PCAP files are detected without any SOAP indication the recorder ask the reporting if there is any record to that PCAP. If yes the processing will follow the normal way, stored or just deleted. But if the reporting has no data there are more possible reasons. CDR data or the reporting could be “late”, so maybe in a few seconds data are in and processed. Or the reporting was just temperately busy or offline, a good idea is wait and try later again. Exactly that the recorder is doing, from build 1070 on the number of trial can be set in a range from 5 to 9999, default value is 5. On earlier build this value was set fix to 1444. Arrived to zero the call is deleted. Deleting recorded calls not knowing about the party involved is critical and therefore the recorder is so carefully.

The real problem is if in a system there are extensions creating PCAP files, but they did not produce CDR tickets / have no CDR license. In this case after a start-up each stored call will produce a PCAP file, the reporting query will fail and the recorder will try later again. To avoid large quantity of PCAP files and slow call processing switch on the reporting feature on each extension creating PCAP files. Or avoid that extension without a reporting creates PCAP files.

Receiving an answer form the reporting the recorder understand immediately the involved parties and can delete the file if the caller was not an Agent or store it.

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

Eventual notes are stored in a file named “2013_06_24_1638_39_o_0800102_7_75c1f48e909d31188fc00903306225f.txt”.

This file is AES encrypt, see relative chapter. If this file is copied with the innovaphone Player it will be automatically decrypt and becomes a standard XML file.

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.

==Encryption==

The setup files for player and recorder are encrypted, as fix key is used an innovaphone specific secret key. The notes are not encrypted while the reporting and security file (the .xml) is encrypted.

So the reporting and security files are encrypted (those ending with “.xml”) using again as default the innovaphone system key. This default encryption key can be replaced with a customer specific key. In the in the setup of the recorder can be defined a customer key. The only reason to define a customer key is to avoid that other customer can decrypt the files, a remote and strange, but thinkable situation.

If this is done in the Recorder also in all Players must be set this customer decrypt key. Be careful in handling that key, because if you forget the key you will lose all encrypted information. The Player can handle contemporaneously the default key and the specific key. There is no update procedure foreseen if you change the key.

Example:

After 3 month of default operation you decide to insert a customer specific encryption key, for example “MySuperSecret007Key”.

You modify also the Player and insert in the setup this new key. Now you will observe that all data, the one of the first 3 month and the following one, will be decrypt automatically correct; the user will see no difference.

After other 5 Month you decide to return to the default key (leaving blank the key field again in recorder and player). Anything is going well, all records are decrypted correctly.

After other 2 Month you decide to enter a key named “MyBrandNewKey”, doing setup of recorder and player. You will observe now that the data of the month period 0 to 3 , 5 to 7 and after Month 7 will be decrypt while Month 3 to 5 (the one with the old key) will be displayed without CDR data and status “unknown”.

Therefore think well about your key, basically once selected it should remain. If you have the list of all Keys you can of cause change it on the fly in a player and decode the records in the period.

=== Audio encryption ===
The security system is based on AES encrypted xml data file. That file contains the CDR data but even the security parameter of the audio file. Therefore if an audio file is manipulated (changed in any way) that will be detected and show in the player (the “manipul” red label is on while off and the green “original” on if the audio file is the original one).

That means that the audio file itself is not encrypted. A fact and feature most customers want (reproducing the file even with other media player). At the end the access to the files should be forbidden to not authorize people.

But there are also customer that have another view and are worried about for example that such an audio file once copied is no more controllable. Or they simply do not thrust that the security features described works fine.

Therefore also the audio file itself can be AES encrypted if that option is switched on in the recorder. The player will detect automatically that an audio file is encrypted and reproduced it anyway.
Here how a player shows a detected Audio encryption:

[[Image:Sec04.png]]

Of cause an encrypted audio file can be reproduced just with the innovaphone player, no other media player will work.

Please note that any innovaphone player can do the decryption, so if you want to assure that just “your” player can reproduce you have to define a customer decrypt key in the recorder (and player).

The recorder shows audio encryption in his extended view:

[[Image:Sec05.png]]

Audio encryption has also disadvantages, recorder and player has more workload.

But the worst thing is the required disk space; in fact size of the audio files will double if encrypted!

==Audio compression==

=== MP3 ===
As default the files are saved in the wave format. More precisely in G711 because wave is a container format and pure PCM would require near the double disk size than G711.

As an option a mp3 compression can be activated. The required disk size is about 75% less, so one minute in wave requires about 1Mb while the same data in mp3 will require 250kb.

If you wonder why the savings are not much higher consider that even the wave format itself is jet compressed as explained.

All other functions like encryption (an encrypted file size is again doubled, so one minute of mp3 audio encrypted requires about 500kb) or reproducing are the same, the user has nothing to do and the player works always in the same mode.

There is just one situation where an action is required: if the recorder works for a certain period with wave and then with mp3 (or vice versa) in the directory of that month there will be mixed files (wave and mp3). The player detect this and shows automatically an additional key where the user must switch between those two formats: if a directory has just one type of files no action is required and the button is hided.

===MP3 Stereo to Stereo conversion===

If the MP3 option is on, files could also be converted form stereo to mono. The file size savings will be nearly 50%, so one minute conversation in mono MP3 requires about 130kB.

Note that conversion from wav to mp3 causes quality lost and stereo to mono even. Once converted, there is no possibility to return to the original format in terms of quality or format. So a bad mono mp3 quality cannot be recovered and even the stereo separation of the cannels cannot be done once converted to mono.

===MP3 just internal channel===

An interesting option in using MP3 is to record just one channel, the left (default) or the right one. The result is a mono file (130kB/min) where just one party is recorded.

If a GW point to an external trunk the internal user is always talking on the left channel. Therefore with this option on just the voice of the internal user is recorded, and doing that in many countries is simply allowed without any restrictions (basically I can record myself).

If recording is done on the phone the channel assignment is vice-versa, the internal caller (the phone) is recorded always in the right channel. Therefore in the setup of the recorder can be selected which cannel should be recorded. That means also that no mixed scenarios (GW and Phone recording) are supported for that feature.

[[Image:RecSetup01.png]]

== Redundancy ==

The recorder is able to handle redundancy scenarios with active and standby devices.
The recorder has to handle 3 sources in different scenarios, the PBX itself, the reporting and the CF or webdav server. Those devices can be all together in one single device (for example in an active IP6010 with reporting and CF and a standby IP6010 with reporting and CF) or on different devices (for example an active and a standby IP800 and two reporting on two different PCs).
Another example is active and standby PBX on Gateways but reporting on a high availability VMware environment, so at the end just one reporting from the recorder point of view.

Therefore the standby can be defined for each of those devices.
If you have no redundancy scenario just leave blank the relative setup values.

=== Active/Standby PBX ===

The failure of the PBX is detected because the SOAP connection will go down. If that happen the recorder will try to establish an alternative link to the standby PBX, if that fails he try again with the primary PBX and so one. That means also that a breakdown of the SOPA connection, for example if you reset the PBX, will require some more seconds until the system is up again (because first the recorder try the standby PBX, this will also fail and after that the main SOAP will be up again).

Note that after a restart the recorder try always the first the main address and then the standby one.

In the panel of the recorder near the PBX status indicator is shown the actual link: if the “ACT” lamp is green than the active PBX is tempted, if gray and the “STB” lamp on the standby link is on.

Please note that the recorder can handle differences in active and standby mode just regarding the IP address. All other parameter must be the same, so for example the path to the reporting must be the same.

=== Active/Standby Reporting ===

If the link to the reporting fails and there is a standby address indicated the recorder try to reach the reporting using the standby IP address for the reporting. If there is just one reporting leave the standby address blank.

As you (hopefully) know the reporting can also be installed on two devices, in that case both PBX (the active and the standby one) will transmit CDR ticket to both reporting applications. The reporting database is replicated and therefore if both devices are on the recorder will find the same informations on each reporting. So in theory if both are on it is not important where the reports are requested. In fact if the active reporting fails the recorder will try a connection to the standby reporting. Now if the active device and relative reporting is on again the recorder could also continue get records from the standby reporting. And he will do that until he is restarted or the standby reporting is down because the reporting will answer. If that is not desired flag the option in the recorder setup (“follow Standby/Active PBX”); doing so the recorder will communicate again with the reporting on the active PBX if the active PBX is up again. So basically the switch is done on link down but also following the SOAP.

=== Active/Standby CF ===

If the PCAP files are buffered on a CF and the PBX goes down also the recorder has to re-map his drive to the standby PBX. In the setup there is a flag in the PCAP section (“follow Standby/Active PBX”), if on the recorder will try to reach the CF of the standby PBX (he takes the IP address of the standby PBX) in the setup.

In scenarios where an external Webdav server is used that flag should not be switched on. The redundancy in that case is demanded to the external devices (for example VMware).

So if you have a “classic” innovaphone redundancy (two IP6010 with reporting and CF) indicate the standby address in the PBX and Reporting panel and switch on the “follow Standby/Active PBX” in the reporting and PCAP panel and anything is fine.

== External Applications ==

The recorder as well the player can be interfaced with external applications like booking or ticketing systems or similar.

The basic idea is that the external application will share common information in his database with the recorder and pilot a player. The user should be able to play a recorder conversation directly from his application interface.

In this chapter the interface is described. If you are not interested is such a feature you can skip this paragraph.

This description is done for the software developer of the external applications. No particular setup for the recorder or player is described, part of other descriptions.

For better understanding the description “hides” all other interfaces.

The “recorder” is a software solution running on a Windows “server” (can also be a simple PC). In the network there will be one or several “players” able to reproducing the recorded conversations.

Under “agent” in this description we understand operators working with the voice recording and using an external application.

It is possible to have a TCP connection between player and recorder but this is not mandatory because the player just access to stored data and read out setup file in the network. The number of player has no limit while the number of player connected to the recorder via TCP is limited to 100. That means that the external application can control up to 100 “agents” trough the recorder. But it is also possible to control a player directly; in this case the remote control has no limit.

Contact us if you have more than 100 agents with voice recording using an external application, we can easily extend this limit.

=== Principle and definition ===

This is the described scenario:

Recorder communicates with Player 1, Player 2 … Player x

The Application server communicates with the Application Client 1, 2, … xx

This description regards the TCP/IP interface in the following picture, the only one to build new from the application point of view.

[[Image:Layout02.png]]

Going on in the description as “Appclient” is intended the User frontend (“Application on terminal x” in the picture).

“AppServer” is called the server of the application (Application Server in the picture), so the server for the ticketing or booking system or whatever.

Keep in mind that just one AppServer can communicate with the Recorder while even each Player can be called even directly from the Appserver or an AppClient. Do not confuse: There are two ways to interface the voice recording system, via TCP and via URL. The smarter and better way is the TCP one. We describe both, read both because in the second section some concepts described in the first one are not repeated.

=== TCP/IP Interfacing ===

This is the preferred and smart way to realize the interface.
All messages and command goes to one single interface as shown in the picture. The Appserver act as a TCP/IP “Master” and will receive from the recorder messages and can send commands to the single Players trough the recorder. So it is a 3rt Party interface, piloting single player using one single IP address. The “play” command for a certain player is send to the recorder (and not to the relative player).

If for example a AppClient wants that the Player starts reproducing a record the command flow will be:

AppClientX press the play key -> AppServer send command to the -> Recorder -> Recorder send a command to -> PlayerX

So the idea is that in the applications is a “Play” and a “Stop” button; if the agent press this button the recording relative to the displayed database record will start to play, pressing stop the play will stop.
Therefore the applications database must contain the record name.

The problem is that the entire information about the record is available just a certain time period after the call end. In most of the cases the application session is terminated or a new one started. Therefore the link is provided in two times.

When voice recording starts, the recorder will send a first record to the AppServer in the following format:

''!FRST!<Extension Number of the Agent>!<UID>!<Agentname>''

<FRST> = indicate that this is the first (of two records)

Extension Number = the Phone number of the Agent

<UID> = a unique ID of the record

<Agentname> = the CN (common name) of the Agent in the PBX

Example:

''!FRST!24!c03a55c2e909d311b6450090331b3e3b!Rossi''

where ''“24”'' is the extension number of the agent, ''“c03a55c2e909d311b6450090331b3e3b”'' is the unique “serial number” of the record and ''“Rossi”'' the name of the agent.

Just the filed ''“!FRST!”'' has a fix length, all the others not; the single field therefore has to be separated searching the “!”.

At this point the applications probably store this information (number, ID and Name) in his database or buffer this info until the Agent has his client ready or similar. Important is that the database record of the application is linked to the record UID.

Basically it is necessary for later data processing that the application server knows the name of the player (in our example “Rossi”). The simplest way to do that is giving the extension in the PBX the right common name (the same name than the application user name). If that is not possible (for example because the application has other items to identify a user) the application has to hold a cross reference table: application user name 1 = recording user name 1 etc. Consider also that not necessarily a record is played only on the player of a certain agent; recording for agent 1 can be required to be played on work station agent 2.

When a call has terminated, the record converted, saved etc. (means, ready to be played) a second record is transmitted from the recording server to the AppServer:

''!LAST!<Extension Number of the Agent>!<UID>!<Track>!<Agentname>''

<Track> = Name of the recorded file, to transmit later to the recorder to play.

Example:

''!LAST!24!93adee5ee909d311b6450090331b3e3b!2013_09_24_1107_39.o.024_1_93adee5ee909d311b6450090331b3e3b.wav!Rossi''

You see that the UID is in again and on the same position; even the extension number and name is repeated. In this way the application can easily search the UID in his database (and the name and/or the number) and when found complete the record entry with the record name (in the example ''2013_09_24_1107_39.o.024_1_93adee5ee909d311b6450090331b3e3b.wav'').
You see the UID is also part of the record name and in theory the original “stand alone” UID in the application database is no longer required. Therefore a overwriting of the UID field in the application database with the record name is possible.

Note: In the actual version a reverse search is not implemented (that the player told the application to display a record). If implemented in the future the search string will be the entire record name and not just the UID, therefore the stand alone UID has no further sense from the voice recording point of view.

From the timing point of view the first message is critical because the UID has to be written until the Agent has opened his application record and that can be even a short time.

The last string is not very time critical because the retrieving of a record and a update can be done in every moment.

The recorder software has a small send buffer (about 25 recordings) where the messages will be buffered if the AppServer is not reachable or the link is down or. If for example the AppServer is switched off and later on again, the recorder will send to the AppServer the FRST and LAST messages buffered during downtime. The Buffer is a Fifo (first in first out) but not an Overflow-Fifo; if full not the oldest but simply all newer messages are lost. The buffering is done just to buffer short time periods, for example to allow a restart of the AppServer PC without losing information (but not for a “offline” operation).

In the application software design should also be considered the possibility that the AppServer receives a First record, is then stopped, and receives the second one after the restart.

That’s all regarding the recording part, now we discuss the remote control of the player.

Remember that a name can be assigned to a player, for external applications that is mandatory. The name can be defined in the player setup; a good idea to simplify the scenario is to give the player the common name of the phone. So in our example we will name the player of the agent “Rossi” just “Rossi”. Not a must of cause, you can call the player of Rossi even “myFirstAgent” or “1234”; but in doing so the external application must store a table where “Rossi” is mapped to “myFirstAgent”. To avoid such complication we suggest unifying the names and assigning to the phone user, Player name and application user in the same one.

To force a certain player to reproduce a certain recording the AppSever has to transmit to the recorder the following command string:

''TRAC!<PN>!<Track>''

<PN>=player name

Example:

''TRAC!Rossi!2013_09_24_1107_39.o.024_1_93adee5ee909d311b6450090331b3e3b.wav''

The Player with the name “Rossi” will start playing the record ''2013_09_24_1107_39.o.024_1_93adee5ee909d311b6450090331b3e3b.wav''.

There are not foreseen any error messages, if for example the player will not find the record or is switched off nothing will be transmitted to the AppServer. In case of record not found on the Player a blank result will indicate the fail. If the recorder start reproducing a record a green “RC” label (for Remote Control) near the play symbol shows that a remote control message and not a manual play key press has started the reproduction.

There are available also other commands:

''STOP'' (Stops the actual play)

''EJEC'' (the actual record is unloaded, the player stops)

''PAUS'' (the actual record is paused)

''PLAY'' (the actual record is played again)

Example:

''EJEC!Rossi''

Will force the player Rossi to stop the reproduction of the track and go in an idle mode.

Generally it is not necessary that the AppServer takes care about the actual Player status or observe command flows. If the Player is for example playing a track and the application server send the command to play another track he will Eject the actual track and play the desired one.

Note also that the player can work minimized in the taskbar and play “invisible”, so the user will see just the application. In the setup of the player can also be defined an automatic popup if a remote play is received and automatic hiding if an eject-command is received. If this is enabled in this way the player is minimized in the taskbar and the user works just with the application screen.

The TCP/IP link between recorder and AppServer is based on the fact that the recorder acts as a slave while the AppServer act as a Server. In the Setup of the recorder the IPadress and the port of the AppServer has to be indicated. The recorder expects on the same port where he is transmitting the response from the AppServer.

The recording server performs a keep alive with an interval settable in seconds. The keep alive message send from the recorder to the AppServer each xx seconds is:

''RecKA''

The message has no further meaning and can be thrown away from the AppServer. If any command is received from the Appserver the keep alive will be skipped and repeated after the, in the recorder setup indicated timespan. Unknown messages form the application server will be throw away from the recorder server.

=== URL Interfacing ===

URL interfacing is available only on a local port (127.0.0.1) and used for interfacing with the reporting (see relative article). The following description is just for internal use.

''<IPLTRAC><PN>''

There are also available the commands

''IPLPLAY''

''IPLSTOP''

''IPLEJECT''

''IPLPAUS''

Example:

''IPLTRAC2013_09_24_1107_39.o.024_1_93adee5ee909d311b6450090331b3e3b.wav''

will force the player to reproduce the indicated record ''2013_09_24_1107_39.o.024_1_93adee5ee909d311b6450090331b3e3b.wav''.

Basically the interface of the player is anyway a TCP/IP interface and no mini Webserver is integrated. But a “Get” from an browser will be detected and decoded, but no answer occurs. That means if you try to launch a command with a browser it will work, but the browser will show you “no page”.

Example:

If you post in your browser “''http://127.0.0.1:9090/IPLPLAY''“, the player will start to play the marked record.

If a port for direct remote control is switched on a “RC on” label is displayed in the player status line.

=== General Note ===

The first UID will be detected form the recording using the SOAP interface in the PBX. Therefore all Agents has to be in the same group that the SOAP user object.

Example: You have a simple user object called “MYSOAP”, put that object in an active group called “Recording” and now put all you Agents in the same group.

Remember that basically recording is done even without the group stuff. So the group is just required to detect the UID in “advanced”. But there is also an additional benefit; the reporting has less stress because the recorder will query the reporting just at the end of the call (knowing via SOAP when the “end” is) while calls without the group are detected as “finished” because the reporting has a valid CDR record, and so the recorder polls each 4 second the reporting on active calls. That means that it is in any case a good idea put the agents in a group, even if no external application is running.

== Recording rules ==

The recording rules describe how the innovaphone PBX and the innovaphone voice recorder works in complex situations.

While basic calls are simple and strait forward in logic, voice recording behavior becomes non clear in complex situations.

What about voice recording if for example a recorded user transfers the call to a “normal” user? Answer: This call will be entirely recorded and booked under the recording user by design; those behaviors are intended under “recording rules”.
From a technical point of view mostly no other solution is possible, form a political point of view any rule could be endless discussed.

Remember that in this chapter “Agent” is just the wording for “user enabled to recording with license” while “user” is a “normal” user, eventually even recording pcap files, but he is not in the recording user group.

In theory senseless recording should not be done. So deleting a record because it should not be stored is a task of the recorder; not recording at all if not necessary is better. That can be achieved avoiding or forcing extensions to the recording gateways or doing recoding directly from the IP-Phone.

The length (or contend) of a record depends; if the recording is done on a GW the entire call will be recorded (if not you will find a note in the rules), from his very first answer to the end. Therefore all the parties involved are even recorded. If recording is done on the phone level just the active call time on that phone will be recorded.

Generally spoken there are not necessary recording rules if the recording is done from the innovaphone IP-Phone: the recording starts when the phone answer the call and ends when the phone hangs up.

So the following table shows the recording rules if recording is done on a GW level.

“External” is the external calling or called party. Of cause if you record even internals calls (forcing all calls in a GW) in some situation the “External” is in reality a internal user, but this will not change the rules. The recorder recognizes the “external” party involved simply because it is the longest number involved.

The recorder stores always even the reporting data and therefore all details are visible in case of doubts. The audio filename anyway if formed just from the internal user number and the external user number even if more numbers are involved in the call (for example in a 3party conference).

Example: External call from number 012345 goes to the Agent number 24, after 3 second he will answer: the result will be a file name like “2014-05-12 14:00_24_i_012345_3_UID”.

Later on in the player you can search “24” or “012345” (or a fraction of it like “0123*” ecc.). In the reporting you can search also all other fields (like other involved extensions) and start the player than from the reporting (see relative function in the innovaphone player).

Note: the following rules works on any type of call transfer (with or without announcement).

“Delete” means that the call will be deleted on the CF. “Call” means that they talk. For example “Agent calls External” indicated the direction and means also that the involved parties talk (or at least produce a pcap file).

Rules:

• External call to Agent = Agent

• External call to User = Deleted

• External call to Agent, User pick-up the call = Agent

• External call to User, Agent pick-up the call = Agent

• External call to broadcast group, Agent answer = Agent

• External call to broadcast group, User answer = Deleted

• External call to User, User hold and transfer to Agent = Agent

• External call to Agent A, Agent A hold and transfer to Agent B = Agent A

• External call to Agent A, Agent B pick up the call = Agent A

• External call to WQ, WQ call XML with DTMF input, XML call WQ, WQ call Agent = Agent (just the external Number is considered, not the DTMF codes and numbers between)

• Agent call External = Agent

• Agent call External, Agent hold and call transfer to User = Agent

• Agent call User, User hold and transfer to External = Deleted

• Agent call External, Agent hold and talk with User but no call transfer = Agent (just external conversation is recorded)

• Agent A call External, Agent A hold and transfer to Agent B = Agent A

• Agent B call External, Agent B hold and transfer to Agent A = Agent B

• User call to Agent, Agent hold and transfer to External = Agent

• User call External, User hold and transfer to Agent = Agent

• User call External = Deleted

• User call External, User hold and talking with Agent but no call transfer = Deleted

• User call Agent, Agent hold and Agent talk with External = Agent (just the external conversation is recorded)

• External call to Agent, Agent has activated a unconditional call forward (CFU) to a User = Deleted

• External Call to Agent, Agent has activated a call forward on busy (CFB) to a User and is busy = Deleted

• External Call to Agent, Agent has activated a call forward on no response (CFNR) to a User, User answer after timeout = Agent

• External call to Agent A, Agent A has activated a unconditional call forward (CFU) to Agent B = Agent B

• External Call to Agent A, Agent A has activated a call forward on busy (CFB) to Agent B and is busy = Agent B

• External Call to Agent A, Agent A has activated a call forward on no response (CFNR) to Agent B, Agent B answer after timeout = Agent A

Note: If Threat call recording is on a call can be marked to store from the calling or called agent. But if both parties are Agent, the called Agent has to dial the code for storing: if the caller dials the code the record will not be saved.

From version 11 on the generated pcap file have a different format. While in former versions the name of a pcap file was a unique single long number form version 11r1 on the ticket as two additional id, one is build form the serial number of the device and the other one if an increasing number. This new format is also generated when recording is done form directly the phone. The recorder can handle both formats automatically, no special setup is required.

We want to focus your attention on the reason of the new format. If for example the recording is done on the phone the phone will generate a new pcap file each time a new call is opened form the PBX point of view.

Example: Phone rings and the user answers, the recording starts with record 1. Then the user put the call on hold and call another extension, this generates record number 2. Then the phone returns to the first call and continuous talking that will be the 3td call. Of cause using the player you will see those 3 calls one after the other (using the user as filter). That this is one situation you recognize looking the reporting details displayed and if you select the 3 calls the player will play one after the other (switch on the loop key) and you listen the entire call in one shoot.

== Known Problems ==

===Open a ticket===

If you have a problem with the recording tool you have to open a ticket as usual. Describe your problem, but send us also the following information:

- Setup of your PBX (with standard password or tell us the password)

- Version of the reporting

- Attach all log and error files and the setup of the recorder. All those files are in the log folder (so zip the entire folder), you find the path and link to the folder in the recorder setup.

- Make some screenshots if possible.

- Open the reporting and do a query where the recorded conversations are in (if possible). Do an export in XML and attached it.

=== No CDR ticket after start-up ===

If a record is not found on the CF and there is no SOAP info about that (for example if you start the recording and there are old terminated calls) the recording checks if the reporting has a related record. If a record is found and it is an Agent involved the record is stored as usual, if no Agent is involved the record will be deleted.

But if there is a recording file found and in the recording there is no related record, the recorder cold simply deletes that record; but this could be fatal. For example the reporting could answer once bad, or the link between the reporting and the PBX is temporary down; in that cases the recording will be lost if simply deleted. Therefore the recorder waits in this situation and asks the reporting again after 2 hours. If even after 2 hours the reporting answer with no record found the file will be deleted (otherwise normally processed and stored or deleted as described before).

Note that the reporting is not aware about the health of the connection between PBX and the Reporting. If the recorder gets no answer from the reporting an alarm occurs and the reporting will not proceed with the storage. But the answer “no record found” is not a clear situation for the software. Therefor this situation has to be avoided and occurs for example if pcaps are recorded, but the users involved have no reporting while the recorder is down and starts up later. So the recorder will “find” pcap files but no reporting information.

During online operation this will not happen, because the SOAP driver will tell the recorder that a specific record has to be deleted, and so the recorder will not check the reporting. This is done even to speed up the recorder because the communication with the reporting is relatively slow. If for example there are many users doing a recording (because a bad setup or simply because a huge PBX) and there are only few users to record a huge amount of files are simply to delete without any further processing. Deleting of files is relatively fast during online operation while in case of startup and then recover historic records it becomes slow, and very slow if there are no CDR tickets. The online deleting of files is just “relatively fast” because the SOAP is very fast but the recorded file has to be closed before deleting. Trying to delete a not closed file will cause an error, if that happen the system after e while will recover, but it is not nice. On top there is no way on a CF to understand if a file is in use or not. Therefore the system will wait 2 seconds before deleting a file.

=== No CDR ticket online ===

There is even an unclear situation in online operation. Imagine that an Agent transmits no CDR information to the reporting (for example because there is no reporting license assigned to that user) or, because of a bad setup in the PBX, the ticket will not arrive to the reporting. A call of an Agent is terminated, the SOAP driver informs the upper layer of the software about that and now the recording ask the reporting about the CDR details. Note that the reporting is not down; the recorder can reach the reporting and get also answers (otherwise the REP alarm would be on). If after a detected call end of an Agent signaled by SOAP and a timeout of 5 seconds no CDR is in the reporting a garbage select routine is activated in the recorder software; this routine ask a second time after other 5 seconds the reporting. If even now the response is “no record found” the reporting waits for this call 2 hours. After 2 hours a third time the reporting is asked, if no record is found the pcap is deleted, otherwise normal processed.

If a record is waiting in the 2 hours timeout status in the field “status” the countdown proceed is shown, for example “P1443”, after 5 seconds “P1442” and so one (number*5/60 = time in minutes to zero).

To fix it just stop the recording, solve the problem if possible (if you are lucky for example the CDR data are in the PBX buffer and will be send to the reporting when connection is up again), if not save the Pcap file, at least it will not be deleted. Then delete the pcap file on the CF to avoid a slowdown of the entire system.

A simple but good idea is to enable the CDR on the recording trunk line, in this case “some information” for the call is retrieved all time and at least the system will not face that problem.

All described can be the result of a bad or erroneous setup, or the customer is aware of that and simply not interested in a good working application. So a “no record” answer could be a real alarm or not. Therefore in the setup that can be selected.

See recording setup, panel reporting, option “Alarm if no CDR ticket found”.

=== Asynchronous reporting/PBX date and time ===

PBX and reporting must have the same date and time. If not, the reporting will detect that and display error and warning messages about a possible manipulation in the files.

So check first the actual date and time of PBX and reporting.

IPVA: Remember that date can be set in the reporting in administration, General, Configure NTP server.

== Related Articles ==

[[Reference10:Player_Voice_Recording]]

[[Reference10:Voice_Recorder/Setup]]

[[Howto:Last_Call_Recording]]

[[Howto:Universal_Track_Recording_Tool]]

[[Howto:Integration_reporting_and_voice_recording]]

[[Howto:Soft-migration_%28looping_in_a_innovaphone_gateway%29_and_Voice_Recording]]

[[Howto:Player_over_http]]

[[Howto:Marking_a_record_in_Voicerecording]]

[[Howto:Voice_Recording_in_Master_Slave_scenarios]]

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

Reference10:Concept Voice Recording 2014

2015-05-06T16:37:29Z

Nfinzel: /* Recording with the IP-Phone */

== Introduction ==

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 records are stored in a first step on the Conpact flash or webdav server and processed then form the recorder tool.

Voice recording can be done on a logical or fiscal gateway (BRI, GW, SIP etc.), and therefore all kind of audio traffic can be recorded. Technically spoken a gateway is doing media relay and writes the audio data to the webdav or CF.

The second way to record is recording directly from the innovaphone IP-Phone. In this case the phone itself writes the audio data to the CF or webdav server.

See the “Scenarios” for further details.

The solution requires an innovaphone PBX, the reporting tool 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.

IMPORTANT: All users that should be recorded need the REPORTING! We recommend reporting for all user, see chapter “Requirements” for further details.

== Requirements ==

===PBX===
You require a PBX version 10 or higher, version 11 is recommended.

===Reporting===

The recording feature requires the innovaphone Reporting. Required Version 10, Build 10043, Version 11 recommended.

At least any user that should be recorded must have the reporting. If user will generate pcap files (do a recording) it is recommended that also those users should have a recording; generally we recommend that all users in the PXN should have the recording on. Here is why: if the recorder found a pcap file (an audio file) he will “ask” the reporting about the involved users. If the reporting has no information (because those users have no reporting) the answer will be a “not found”. Therefore the recorder will try later on more times to found the record in the recording, all that will slow down the entire system.

=== Recorder ===

This document describes Build 10089. Please note that from build 10084 on no more drive mapping is done and 10089 supports https.

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.
The stores voce data is not PCM but a G.711 format in a wave container. PCM require much more disk space and is not used for storing. The audio files can also be encrypted. Encryption would double the required disk space. The recorded conversation is a stereo file where the external caller is on the left channel whiles the internal one in the right channel. It is possible down mix the conversation to mono; this would save about 50%. It is also possible compress the audio data to mp3.

The following table shows the required disk space for one minute of conversation:

[[Image:RecSetup07.png]]

Example: 500GB Hard disk, mp3 compression without encryption -> 1.389 days = 3,8 years of conversation

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 11 innovaphone PBX and a Version 11 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.

Remember that the CF is a relative slow drive, you will note this if you copy a file from the CF to the local HD of your PC. Exact this file copy is one of the task of the recorder, even a critical one (so not a good idea do anything else in between). The result is that the copy of a huge file (a long conversation) or many files will virtually froze the recorder software. In reality the recorder is just hanging around and waits that the file copy is finally done. So a recording on an external webdav server will solve this, but the CF has the nice flair working even if all PC’s are down. Take your choices and live with them.

Require Framework 4.5.

=== Codecs ===
Recording can only be done in G.711 or G.729. Calls with different codes (e.g. G.722) will still be recorded, but no wave files will be converted!

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

In theory it should work on any CPU, the Player was tested under Win7 32BIT, Win7 64Bit and Win8 64Bit.

===License===

The license model is based on user, so for each user to record a license is required.

The current implementation allows a recording of objects of type user or executive. Recordings on other objects will be discarded.

So in short: Per recorded user or executive object you need to have
* one recording license
* one reporting license

In start-up the recorder will read out the number of recording license in the PBX. After that the recorder will read out all users and check if a user is in the recording group (defined in the recorder setup). If a user with that group is found one license is counted down. If there are no more license but user in group detected they will be skipped. The recorder shows how many license where detected in the PBX and how many user are in the recording group. If there are more users than licenses a warning is show.

Remember that just users in the recorder user table are recorded; all other records are automatic deleted! This can be usefully if for example for internal reasons not just the user to record passes through the recording gateway but also others; not being in the group the records will be destroyed. But of course this will cause senseless PBX CPU workload because a recording anyway is done, just the recorder will delete after the files.

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

== Feature list ==

=== General ===

• Using an innovaphone IP-Phone set immediately after call end the recording can be listened using the phone. One feature key stroke and the conversation is reproduced and repeated endless (auto replay). This call can also be transferred or put in a 3 party conference (immediate sharing)

• Online Help and tooltips for application and setup

• Setup password protected, setup files are encrypted

• Recorder in Demo Mode (20 minutes) , Player for free

• Many recorder in one system and unlimited number of players

=== Recorder ===

• Recording of any type of calls direction

• Recording of calls from any device: IP-Phones (innovaphone and 3rt Party), analogue phones, GSM (mobility), IP-DECT

• Recording of calls from/to legacy PBX (smooth migration)

• Recording can be done in a logical gateway or direct from a innovaphone phone set

• Recording of encrypted calls

• Standard und thread call recording. If thread call recording is on after a settable time period (for example 5 minutes) a call will be automatically deleted. If the user calls inside the time period a code the last call will be saved. This marking to keep the recorded call can be done from any type of phone. If the phone is a innovaphone IP Phone the marking can be done also during conversation

• Storage of all relevant data including the time to answer for each call

• Detail protocol of each call, documentation of the entire call flow, not just the recording period but even previous and following one. Detail report on all call situations, transfer, call forwarding, pick-up, group call, conference etc. Also calls in waiting queues or announcements are reported with second accuracy

• Encrypted protocol data

• Display number of channels in recording with start timestamp

• Error and Event log files

• Email alert in case of master alarm

• Automatic backup (copy to mass storage archive)

• Automatic delete of records older than 2-99 month (not on archives)

• Recordings are saved as wave files, can be reproduced with any player

• Wave data integrity supervision

• File name contains primary data (Timestamp, Caller and called, direction, time to answer, UID)

• Counter of recorded conversations

• Data Link to player, remote control of the recorder from player

• Interface to external applications, via TCP or URL, recorder provides data for later retrieving. Player can be controlled sending commands to the recorder (3rd party)

• Mark record during a conversation on the IP-Phone (build 1077)

• Https from Build 10087 on

• Salve sites from Build 10089 on

=== Player ===

• Integrity of the recorded wave files are recognized and displayed

• Agent note, a Player displays automatically agent notes and can add text notes to each call

• Integration with iQM server, display of missed calls, possibility to recall immediately

• Naming of Players

• Month and Day filter

• Filter for internal and external number with wildcards

• Filter for incoming and outgoing calls

• View of oldest or newest call on top

• SOS mode can be switched on/off with just one click. If on all unnecessary key are hide, the newest calls are displayed on top of the call list and filters are switched off

• Selection of calls, one single call, more single selected calls, from to, all

• Online search and display, can be switched off

• Copy, move and delete of calls

• Move and delete operations are logged in centralized manipulation log

• Permissions

• Multiple selected calls can are transferred automatically in a playlist and can be reproduced

• Display record size

• Display number of records in playlist and actual play

• Jump forward and backward in playlist

• Jump to next/previous title in search result list if playlist contains just one record

• Marc record in playlist, select actual record and clear all others

• Play one title after the other in playlist

• Play a beep if record change in playlist (loop playlist)

• Repeat play (loop record), up to 4 positions, stored automatically

• Repeat play of all stored memory positions

• Display internal and external number with name resolution

• Display timestamp, time to answer an call ID

• Display System and Player status

• Display if local remote control interface is on

• Display of play was forced be recorder remote control

• Keys for Stop, Play, Fast Forwarding, Rewind, Pause and Eject

• Display duration record

• Display elapsed time or count down, switchable

• Original time elapsing display

• Progress bar adjustable, direct jump to selected position, drag and drop

• Start and Stop position can be marked an played in loop (selection loop)

• Volume control with audio meter and peek indication

• Delta level Indication (L-R and R-L meter)

• Overflow level audio meter

• Enhanced sensitivity for audio meter

• Attenuation left and right cannel adjustable

• Audio setup can be stored and recalled

• Audio level at maximum

• Levels are stored and set on restart

• Level meter with peek indicator for left and right cannel

• Mute

• Large additional display with call details

• Automatic decryption if files are copied

• Player can be limited to display just calls of one extension

• Communication with recorder, display of link status, last master alarm and cannels in recording

• Reset recorder from player

• Search an play on backup directories

• Operate as Media player, reproduction of audio format wav, mp3, wmp and video format avi, wmv, mp4 and mpg

• 1rst and 3rd party remote control

• Document security, manipulation is detected and displayed

• Browse last played records (build 1071)

• Browse marked records on this player (build 1071)

• Browse marked records in a system wide available directory (build 1071)

• Mark records on player and for system wide access (build 1071)

• Copy records marked in a player to the system wide available directory (build 1071)

• Write a central log for all player listening’s (build 1071)

• Work over hhtp connections (build 1074)

• Limit view to a list of extensions (build 1077)

== Scenarios ==

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 on a central point ===

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 or G729 on a logical gateway as endpoint. If you want record internal calls in this way calls must always transit a logical gateway (with the media relay flag on).

=== Recording with the IP-Phone ===

Recording can be done also directly from the innovaphone IP-Phone.
If switched on all calls from and to this phone are recorded, there are no recording rules. Calls could be stored in different files, because a new call means also a new file. If for example a phone put on hold a conversations and establish a second call this second call will be stored a an separate file.

Doing voice recording using the IP-Phone or using a Gateway has advantages and disadvantages; it depends on your point of view and the scenario.

Here some issues to remember:

Recording on a gateway is like the old “ISDN Recording”: anything passing that interface is recorded. That has the advantage that any type of endpoint (IP, 3rt party, Dect, analog etc.) will be recorded. The disadvantage is that internal calls are not recorded. Also the CPU load of the PBX will rise while recording with an IP-Phone has nearly no influence.

Recording directly from the Phone has the limitation that just innovaphone IP-Phone are able to doing that. Only innovaphone IP-Phones IP2x2 series can performing Voice Recording directly.
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).

In the V11r1 IP recording on the phone can just switched on or off in the setup, not from the user. In V11r2 recording can switched on and off by the user (similar to the 3party version).

Note: The recording described here does not require a phone 3 party conference; therefore a 3party conference is possible on the phone while recording is running.

== Recording Modes ==
=== Standard Recording ===

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

Note: A recorder canoperate just in one mode (for example "Standard"). Mixed scenario are possible but require two or more recorders, the setup in this case has to be done very carefully.

=== 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 sub-directory TCR in your PCAP recording directory and copy the xml in, create a VM-Object in the PBX and insert those parameters in the recorder setup (TCR panel). Example: Your PCAp directory is http://172.16.88.98/DRIVE/CF0/REC, therefore the directory create is is http://172.16.88.98/DRIVE/CF0/REC/TCR. 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.

=== Random recording ===
The recorder can work in this mode also as an alternative to the Standard- or Threat call recording. Random recording will record just a sample of calls on normal Agents (User), typically for quality check purposes.

The system allows record just each x call where x can be set in the setup. The system can even record just each y call for an agent. Only “to recording” calls are counted, not calls in general.

Example: “Record in System just each 3. Call”’: the system will store one record and then skip the following 2 one.

Example: “Record for a Gent just each 2. Call”: for each agent one call will be recorded and one not.

Both setups can be set isolated, but combined (3rd in system and 2nd for a agent) the system will first skip 2 calls and then for the specific agent skip each 2nd one.

Calls typically are not foreseeable especially if they are more agent involved and therefore it is for a single agent a “random” recording.

This feature requires build 1071 or higher.

=== Manual/Transparent/Optional recording ===

V11r2 (in the Phone) is required.

If the recording is done using a innovaphone IP Phone there are 3 recording modes possible:

- Manual: the user switch recording on/off using a Feature key

- Transparent: recording is always on

- Optional: recording is on by default but the user can switch it off using a feature key

The manual and optional mode is widely used because the operator can switch on and off recording during a conversation. For example if the customer want to buy the operator starts recording and give the advice that from now on the recording is on (by the way: that can be played also automatically modifying the last call recording xml). Switching off recording is usefully also if for example during a conversation a secret info (like a password) is stated and should not be recorded ad all.

The Recording link (url) to the Webdav or CF is defined in the user setup:

[[Image:RecSetup08.png]]

The mode is selected in the "recording" section:

[[Image:RecSetup09.png]]

Note: The recording described here does NOT require a phone 3 party conference; therefore a 3party conference is possible on the phone while recording is running.

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

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

(*) = Option

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.

== Installation Step 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 course, 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/System_Setup#Gateway_Setup . If you want to do a test with internal phones you have to assure that in call 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 course 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. Start the application and open the setup.

== Installation ==

While the Recorder works “hidden” for the user, the Player has a huge user interface. The Player is typically installed on one or more PC of users. Therefore for the Player more effort to design a foolproof interface was done. The Player description is available, 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 is even encrypt.

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.

=== Date ===

As most application also the recorder requires a correct date and time. But also the PBX Date and time must be correct and the same as the one on the recording PC.

Basically obviously, writing a file all file data should be correct, and also the CDR ticket data should.

So verify that both, PBX and PC have always a correct and synchronized date and time.

== Voice Recorder operation ==

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

[[Image:RecE111B1.png]]

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

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

*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:RecE111B2.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.

The following picture shows two alarms, Reporting (because there where files without CDR records) and Software (because there was a license overflow).

[[Image:RecXX.png]]

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

Basically calls that should not be recorded should not be recorded even on the CF, this is desirable, but not always feasible.

In normal operations the recorder is connected to the PBX with a SOAP link and can so detect when a call is finished and the party involved. If there is a PCAP file and a SOAP connection fine, because in the very first step anything is clear and the recorder can decide to save or to just delete the PCAP file. But there is also the possibility that the recorder starts up later and “found” PCAP files stored in the meantime. In this case there could be or even not any SOAP information, if the call terminated before the recorder starts there will no SOAP info. Therefore if PCAP files are detected without any SOAP indication the recorder ask the reporting if there is any record to that PCAP. If yes the processing will follow the normal way, stored or just deleted. But if the reporting has no data there are more possible reasons. CDR data or the reporting could be “late”, so maybe in a few seconds data are in and processed. Or the reporting was just temperately busy or offline, a good idea is wait and try later again. Exactly that the recorder is doing, from build 1070 on the number of trial can be set in a range from 5 to 9999, default value is 5. On earlier build this value was set fix to 1444. Arrived to zero the call is deleted. Deleting recorded calls not knowing about the party involved is critical and therefore the recorder is so carefully.

The real problem is if in a system there are extensions creating PCAP files, but they did not produce CDR tickets / have no CDR license. In this case after a start-up each stored call will produce a PCAP file, the reporting query will fail and the recorder will try later again. To avoid large quantity of PCAP files and slow call processing switch on the reporting feature on each extension creating PCAP files. Or avoid that extension without a reporting creates PCAP files.

Receiving an answer form the reporting the recorder understand immediately the involved parties and can delete the file if the caller was not an Agent or store it.

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

Eventual notes are stored in a file named “2013_06_24_1638_39_o_0800102_7_75c1f48e909d31188fc00903306225f.txt”.

This file is AES encrypt, see relative chapter. If this file is copied with the innovaphone Player it will be automatically decrypt and becomes a standard XML file.

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.

==Encryption==

The setup files for player and recorder are encrypted, as fix key is used an innovaphone specific secret key. The notes are not encrypted while the reporting and security file (the .xml) is encrypted.

So the reporting and security files are encrypted (those ending with “.xml”) using again as default the innovaphone system key. This default encryption key can be replaced with a customer specific key. In the in the setup of the recorder can be defined a customer key. The only reason to define a customer key is to avoid that other customer can decrypt the files, a remote and strange, but thinkable situation.

If this is done in the Recorder also in all Players must be set this customer decrypt key. Be careful in handling that key, because if you forget the key you will lose all encrypted information. The Player can handle contemporaneously the default key and the specific key. There is no update procedure foreseen if you change the key.

Example:

After 3 month of default operation you decide to insert a customer specific encryption key, for example “MySuperSecret007Key”.

You modify also the Player and insert in the setup this new key. Now you will observe that all data, the one of the first 3 month and the following one, will be decrypt automatically correct; the user will see no difference.

After other 5 Month you decide to return to the default key (leaving blank the key field again in recorder and player). Anything is going well, all records are decrypted correctly.

After other 2 Month you decide to enter a key named “MyBrandNewKey”, doing setup of recorder and player. You will observe now that the data of the month period 0 to 3 , 5 to 7 and after Month 7 will be decrypt while Month 3 to 5 (the one with the old key) will be displayed without CDR data and status “unknown”.

Therefore think well about your key, basically once selected it should remain. If you have the list of all Keys you can of cause change it on the fly in a player and decode the records in the period.

=== Audio encryption ===
The security system is based on AES encrypted xml data file. That file contains the CDR data but even the security parameter of the audio file. Therefore if an audio file is manipulated (changed in any way) that will be detected and show in the player (the “manipul” red label is on while off and the green “original” on if the audio file is the original one).

That means that the audio file itself is not encrypted. A fact and feature most customers want (reproducing the file even with other media player). At the end the access to the files should be forbidden to not authorize people.

But there are also customer that have another view and are worried about for example that such an audio file once copied is no more controllable. Or they simply do not thrust that the security features described works fine.

Therefore also the audio file itself can be AES encrypted if that option is switched on in the recorder. The player will detect automatically that an audio file is encrypted and reproduced it anyway.
Here how a player shows a detected Audio encryption:

[[Image:Sec04.png]]

Of cause an encrypted audio file can be reproduced just with the innovaphone player, no other media player will work.

Please note that any innovaphone player can do the decryption, so if you want to assure that just “your” player can reproduce you have to define a customer decrypt key in the recorder (and player).

The recorder shows audio encryption in his extended view:

[[Image:Sec05.png]]

Audio encryption has also disadvantages, recorder and player has more workload.

But the worst thing is the required disk space; in fact size of the audio files will double if encrypted!

==Audio compression==

=== MP3 ===
As default the files are saved in the wave format. More precisely in G711 because wave is a container format and pure PCM would require near the double disk size than G711.

As an option a mp3 compression can be activated. The required disk size is about 75% less, so one minute in wave requires about 1Mb while the same data in mp3 will require 250kb.

If you wonder why the savings are not much higher consider that even the wave format itself is jet compressed as explained.

All other functions like encryption (an encrypted file size is again doubled, so one minute of mp3 audio encrypted requires about 500kb) or reproducing are the same, the user has nothing to do and the player works always in the same mode.

There is just one situation where an action is required: if the recorder works for a certain period with wave and then with mp3 (or vice versa) in the directory of that month there will be mixed files (wave and mp3). The player detect this and shows automatically an additional key where the user must switch between those two formats: if a directory has just one type of files no action is required and the button is hided.

===MP3 Stereo to Stereo conversion===

If the MP3 option is on, files could also be converted form stereo to mono. The file size savings will be nearly 50%, so one minute conversation in mono MP3 requires about 130kB.

Note that conversion from wav to mp3 causes quality lost and stereo to mono even. Once converted, there is no possibility to return to the original format in terms of quality or format. So a bad mono mp3 quality cannot be recovered and even the stereo separation of the cannels cannot be done once converted to mono.

===MP3 just internal channel===

An interesting option in using MP3 is to record just one channel, the left (default) or the right one. The result is a mono file (130kB/min) where just one party is recorded.

If a GW point to an external trunk the internal user is always talking on the left channel. Therefore with this option on just the voice of the internal user is recorded, and doing that in many countries is simply allowed without any restrictions (basically I can record myself).

If recording is done on the phone the channel assignment is vice-versa, the internal caller (the phone) is recorded always in the right channel. Therefore in the setup of the recorder can be selected which cannel should be recorded. That means also that no mixed scenarios (GW and Phone recording) are supported for that feature.

[[Image:RecSetup01.png]]

== Redundancy ==

The recorder is able to handle redundancy scenarios with active and standby devices.
The recorder has to handle 3 sources in different scenarios, the PBX itself, the reporting and the CF or webdav server. Those devices can be all together in one single device (for example in an active IP6010 with reporting and CF and a standby IP6010 with reporting and CF) or on different devices (for example an active and a standby IP800 and two reporting on two different PCs).
Another example is active and standby PBX on Gateways but reporting on a high availability VMware environment, so at the end just one reporting from the recorder point of view.

Therefore the standby can be defined for each of those devices.
If you have no redundancy scenario just leave blank the relative setup values.

=== Active/Standby PBX ===

The failure of the PBX is detected because the SOAP connection will go down. If that happen the recorder will try to establish an alternative link to the standby PBX, if that fails he try again with the primary PBX and so one. That means also that a breakdown of the SOPA connection, for example if you reset the PBX, will require some more seconds until the system is up again (because first the recorder try the standby PBX, this will also fail and after that the main SOAP will be up again).

Note that after a restart the recorder try always the first the main address and then the standby one.

In the panel of the recorder near the PBX status indicator is shown the actual link: if the “ACT” lamp is green than the active PBX is tempted, if gray and the “STB” lamp on the standby link is on.

Please note that the recorder can handle differences in active and standby mode just regarding the IP address. All other parameter must be the same, so for example the path to the reporting must be the same.

=== Active/Standby Reporting ===

If the link to the reporting fails and there is a standby address indicated the recorder try to reach the reporting using the standby IP address for the reporting. If there is just one reporting leave the standby address blank.

As you (hopefully) know the reporting can also be installed on two devices, in that case both PBX (the active and the standby one) will transmit CDR ticket to both reporting applications. The reporting database is replicated and therefore if both devices are on the recorder will find the same informations on each reporting. So in theory if both are on it is not important where the reports are requested. In fact if the active reporting fails the recorder will try a connection to the standby reporting. Now if the active device and relative reporting is on again the recorder could also continue get records from the standby reporting. And he will do that until he is restarted or the standby reporting is down because the reporting will answer. If that is not desired flag the option in the recorder setup (“follow Standby/Active PBX”); doing so the recorder will communicate again with the reporting on the active PBX if the active PBX is up again. So basically the switch is done on link down but also following the SOAP.

=== Active/Standby CF ===

If the PCAP files are buffered on a CF and the PBX goes down also the recorder has to re-map his drive to the standby PBX. In the setup there is a flag in the PCAP section (“follow Standby/Active PBX”), if on the recorder will try to reach the CF of the standby PBX (he takes the IP address of the standby PBX) in the setup.

In scenarios where an external Webdav server is used that flag should not be switched on. The redundancy in that case is demanded to the external devices (for example VMware).

So if you have a “classic” innovaphone redundancy (two IP6010 with reporting and CF) indicate the standby address in the PBX and Reporting panel and switch on the “follow Standby/Active PBX” in the reporting and PCAP panel and anything is fine.

== External Applications ==

The recorder as well the player can be interfaced with external applications like booking or ticketing systems or similar.

The basic idea is that the external application will share common information in his database with the recorder and pilot a player. The user should be able to play a recorder conversation directly from his application interface.

In this chapter the interface is described. If you are not interested is such a feature you can skip this paragraph.

This description is done for the software developer of the external applications. No particular setup for the recorder or player is described, part of other descriptions.

For better understanding the description “hides” all other interfaces.

The “recorder” is a software solution running on a Windows “server” (can also be a simple PC). In the network there will be one or several “players” able to reproducing the recorded conversations.

Under “agent” in this description we understand operators working with the voice recording and using an external application.

It is possible to have a TCP connection between player and recorder but this is not mandatory because the player just access to stored data and read out setup file in the network. The number of player has no limit while the number of player connected to the recorder via TCP is limited to 100. That means that the external application can control up to 100 “agents” trough the recorder. But it is also possible to control a player directly; in this case the remote control has no limit.

Contact us if you have more than 100 agents with voice recording using an external application, we can easily extend this limit.

=== Principle and definition ===

This is the described scenario:

Recorder communicates with Player 1, Player 2 … Player x

The Application server communicates with the Application Client 1, 2, … xx

This description regards the TCP/IP interface in the following picture, the only one to build new from the application point of view.

[[Image:Layout02.png]]

Going on in the description as “Appclient” is intended the User frontend (“Application on terminal x” in the picture).

“AppServer” is called the server of the application (Application Server in the picture), so the server for the ticketing or booking system or whatever.

Keep in mind that just one AppServer can communicate with the Recorder while even each Player can be called even directly from the Appserver or an AppClient. Do not confuse: There are two ways to interface the voice recording system, via TCP and via URL. The smarter and better way is the TCP one. We describe both, read both because in the second section some concepts described in the first one are not repeated.

=== TCP/IP Interfacing ===

This is the preferred and smart way to realize the interface.
All messages and command goes to one single interface as shown in the picture. The Appserver act as a TCP/IP “Master” and will receive from the recorder messages and can send commands to the single Players trough the recorder. So it is a 3rt Party interface, piloting single player using one single IP address. The “play” command for a certain player is send to the recorder (and not to the relative player).

If for example a AppClient wants that the Player starts reproducing a record the command flow will be:

AppClientX press the play key -> AppServer send command to the -> Recorder -> Recorder send a command to -> PlayerX

So the idea is that in the applications is a “Play” and a “Stop” button; if the agent press this button the recording relative to the displayed database record will start to play, pressing stop the play will stop.
Therefore the applications database must contain the record name.

The problem is that the entire information about the record is available just a certain time period after the call end. In most of the cases the application session is terminated or a new one started. Therefore the link is provided in two times.

When voice recording starts, the recorder will send a first record to the AppServer in the following format:

''!FRST!<Extension Number of the Agent>!<UID>!<Agentname>''

<FRST> = indicate that this is the first (of two records)

Extension Number = the Phone number of the Agent

<UID> = a unique ID of the record

<Agentname> = the CN (common name) of the Agent in the PBX

Example:

''!FRST!24!c03a55c2e909d311b6450090331b3e3b!Rossi''

where ''“24”'' is the extension number of the agent, ''“c03a55c2e909d311b6450090331b3e3b”'' is the unique “serial number” of the record and ''“Rossi”'' the name of the agent.

Just the filed ''“!FRST!”'' has a fix length, all the others not; the single field therefore has to be separated searching the “!”.

At this point the applications probably store this information (number, ID and Name) in his database or buffer this info until the Agent has his client ready or similar. Important is that the database record of the application is linked to the record UID.

Basically it is necessary for later data processing that the application server knows the name of the player (in our example “Rossi”). The simplest way to do that is giving the extension in the PBX the right common name (the same name than the application user name). If that is not possible (for example because the application has other items to identify a user) the application has to hold a cross reference table: application user name 1 = recording user name 1 etc. Consider also that not necessarily a record is played only on the player of a certain agent; recording for agent 1 can be required to be played on work station agent 2.

When a call has terminated, the record converted, saved etc. (means, ready to be played) a second record is transmitted from the recording server to the AppServer:

''!LAST!<Extension Number of the Agent>!<UID>!<Track>!<Agentname>''

<Track> = Name of the recorded file, to transmit later to the recorder to play.

Example:

''!LAST!24!93adee5ee909d311b6450090331b3e3b!2013_09_24_1107_39.o.024_1_93adee5ee909d311b6450090331b3e3b.wav!Rossi''

You see that the UID is in again and on the same position; even the extension number and name is repeated. In this way the application can easily search the UID in his database (and the name and/or the number) and when found complete the record entry with the record name (in the example ''2013_09_24_1107_39.o.024_1_93adee5ee909d311b6450090331b3e3b.wav'').
You see the UID is also part of the record name and in theory the original “stand alone” UID in the application database is no longer required. Therefore a overwriting of the UID field in the application database with the record name is possible.

Note: In the actual version a reverse search is not implemented (that the player told the application to display a record). If implemented in the future the search string will be the entire record name and not just the UID, therefore the stand alone UID has no further sense from the voice recording point of view.

From the timing point of view the first message is critical because the UID has to be written until the Agent has opened his application record and that can be even a short time.

The last string is not very time critical because the retrieving of a record and a update can be done in every moment.

The recorder software has a small send buffer (about 25 recordings) where the messages will be buffered if the AppServer is not reachable or the link is down or. If for example the AppServer is switched off and later on again, the recorder will send to the AppServer the FRST and LAST messages buffered during downtime. The Buffer is a Fifo (first in first out) but not an Overflow-Fifo; if full not the oldest but simply all newer messages are lost. The buffering is done just to buffer short time periods, for example to allow a restart of the AppServer PC without losing information (but not for a “offline” operation).

In the application software design should also be considered the possibility that the AppServer receives a First record, is then stopped, and receives the second one after the restart.

That’s all regarding the recording part, now we discuss the remote control of the player.

Remember that a name can be assigned to a player, for external applications that is mandatory. The name can be defined in the player setup; a good idea to simplify the scenario is to give the player the common name of the phone. So in our example we will name the player of the agent “Rossi” just “Rossi”. Not a must of cause, you can call the player of Rossi even “myFirstAgent” or “1234”; but in doing so the external application must store a table where “Rossi” is mapped to “myFirstAgent”. To avoid such complication we suggest unifying the names and assigning to the phone user, Player name and application user in the same one.

To force a certain player to reproduce a certain recording the AppSever has to transmit to the recorder the following command string:

''TRAC!<PN>!<Track>''

<PN>=player name

Example:

''TRAC!Rossi!2013_09_24_1107_39.o.024_1_93adee5ee909d311b6450090331b3e3b.wav''

The Player with the name “Rossi” will start playing the record ''2013_09_24_1107_39.o.024_1_93adee5ee909d311b6450090331b3e3b.wav''.

There are not foreseen any error messages, if for example the player will not find the record or is switched off nothing will be transmitted to the AppServer. In case of record not found on the Player a blank result will indicate the fail. If the recorder start reproducing a record a green “RC” label (for Remote Control) near the play symbol shows that a remote control message and not a manual play key press has started the reproduction.

There are available also other commands:

''STOP'' (Stops the actual play)

''EJEC'' (the actual record is unloaded, the player stops)

''PAUS'' (the actual record is paused)

''PLAY'' (the actual record is played again)

Example:

''EJEC!Rossi''

Will force the player Rossi to stop the reproduction of the track and go in an idle mode.

Generally it is not necessary that the AppServer takes care about the actual Player status or observe command flows. If the Player is for example playing a track and the application server send the command to play another track he will Eject the actual track and play the desired one.

Note also that the player can work minimized in the taskbar and play “invisible”, so the user will see just the application. In the setup of the player can also be defined an automatic popup if a remote play is received and automatic hiding if an eject-command is received. If this is enabled in this way the player is minimized in the taskbar and the user works just with the application screen.

The TCP/IP link between recorder and AppServer is based on the fact that the recorder acts as a slave while the AppServer act as a Server. In the Setup of the recorder the IPadress and the port of the AppServer has to be indicated. The recorder expects on the same port where he is transmitting the response from the AppServer.

The recording server performs a keep alive with an interval settable in seconds. The keep alive message send from the recorder to the AppServer each xx seconds is:

''RecKA''

The message has no further meaning and can be thrown away from the AppServer. If any command is received from the Appserver the keep alive will be skipped and repeated after the, in the recorder setup indicated timespan. Unknown messages form the application server will be throw away from the recorder server.

=== URL Interfacing ===

URL interfacing is available only on a local port (127.0.0.1) and used for interfacing with the reporting (see relative article). The following description is just for internal use.

''<IPLTRAC><PN>''

There are also available the commands

''IPLPLAY''

''IPLSTOP''

''IPLEJECT''

''IPLPAUS''

Example:

''IPLTRAC2013_09_24_1107_39.o.024_1_93adee5ee909d311b6450090331b3e3b.wav''

will force the player to reproduce the indicated record ''2013_09_24_1107_39.o.024_1_93adee5ee909d311b6450090331b3e3b.wav''.

Basically the interface of the player is anyway a TCP/IP interface and no mini Webserver is integrated. But a “Get” from an browser will be detected and decoded, but no answer occurs. That means if you try to launch a command with a browser it will work, but the browser will show you “no page”.

Example:

If you post in your browser “''http://127.0.0.1:9090/IPLPLAY''“, the player will start to play the marked record.

If a port for direct remote control is switched on a “RC on” label is displayed in the player status line.

=== General Note ===

The first UID will be detected form the recording using the SOAP interface in the PBX. Therefore all Agents has to be in the same group that the SOAP user object.

Example: You have a simple user object called “MYSOAP”, put that object in an active group called “Recording” and now put all you Agents in the same group.

Remember that basically recording is done even without the group stuff. So the group is just required to detect the UID in “advanced”. But there is also an additional benefit; the reporting has less stress because the recorder will query the reporting just at the end of the call (knowing via SOAP when the “end” is) while calls without the group are detected as “finished” because the reporting has a valid CDR record, and so the recorder polls each 4 second the reporting on active calls. That means that it is in any case a good idea put the agents in a group, even if no external application is running.

== Recording rules ==

The recording rules describe how the innovaphone PBX and the innovaphone voice recorder works in complex situations.

While basic calls are simple and strait forward in logic, voice recording behavior becomes non clear in complex situations.

What about voice recording if for example a recorded user transfers the call to a “normal” user? Answer: This call will be entirely recorded and booked under the recording user by design; those behaviors are intended under “recording rules”.
From a technical point of view mostly no other solution is possible, form a political point of view any rule could be endless discussed.

Remember that in this chapter “Agent” is just the wording for “user enabled to recording with license” while “user” is a “normal” user, eventually even recording pcap files, but he is not in the recording user group.

In theory senseless recording should not be done. So deleting a record because it should not be stored is a task of the recorder; not recording at all if not necessary is better. That can be achieved avoiding or forcing extensions to the recording gateways or doing recoding directly from the IP-Phone.

The length (or contend) of a record depends; if the recording is done on a GW the entire call will be recorded (if not you will find a note in the rules), from his very first answer to the end. Therefore all the parties involved are even recorded. If recording is done on the phone level just the active call time on that phone will be recorded.

Generally spoken there are not necessary recording rules if the recording is done from the innovaphone IP-Phone: the recording starts when the phone answer the call and ends when the phone hangs up.

So the following table shows the recording rules if recording is done on a GW level.

“External” is the external calling or called party. Of cause if you record even internals calls (forcing all calls in a GW) in some situation the “External” is in reality a internal user, but this will not change the rules. The recorder recognizes the “external” party involved simply because it is the longest number involved.

The recorder stores always even the reporting data and therefore all details are visible in case of doubts. The audio filename anyway if formed just from the internal user number and the external user number even if more numbers are involved in the call (for example in a 3party conference).

Example: External call from number 012345 goes to the Agent number 24, after 3 second he will answer: the result will be a file name like “2014-05-12 14:00_24_i_012345_3_UID”.

Later on in the player you can search “24” or “012345” (or a fraction of it like “0123*” ecc.). In the reporting you can search also all other fields (like other involved extensions) and start the player than from the reporting (see relative function in the innovaphone player).

Note: the following rules works on any type of call transfer (with or without announcement).

“Delete” means that the call will be deleted on the CF. “Call” means that they talk. For example “Agent calls External” indicated the direction and means also that the involved parties talk (or at least produce a pcap file).

Rules:

• External call to Agent = Agent

• External call to User = Deleted

• External call to Agent, User pick-up the call = Agent

• External call to User, Agent pick-up the call = Agent

• External call to broadcast group, Agent answer = Agent

• External call to broadcast group, User answer = Deleted

• External call to User, User hold and transfer to Agent = Agent

• External call to Agent A, Agent A hold and transfer to Agent B = Agent A

• External call to Agent A, Agent B pick up the call = Agent A

• External call to WQ, WQ call XML with DTMF input, XML call WQ, WQ call Agent = Agent (just the external Number is considered, not the DTMF codes and numbers between)

• Agent call External = Agent

• Agent call External, Agent hold and call transfer to User = Agent

• Agent call User, User hold and transfer to External = Deleted

• Agent call External, Agent hold and talk with User but no call transfer = Agent (just external conversation is recorded)

• Agent A call External, Agent A hold and transfer to Agent B = Agent A

• Agent B call External, Agent B hold and transfer to Agent A = Agent B

• User call to Agent, Agent hold and transfer to External = Agent

• User call External, User hold and transfer to Agent = Agent

• User call External = Deleted

• User call External, User hold and talking with Agent but no call transfer = Deleted

• User call Agent, Agent hold and Agent talk with External = Agent (just the external conversation is recorded)

• External call to Agent, Agent has activated a unconditional call forward (CFU) to a User = Deleted

• External Call to Agent, Agent has activated a call forward on busy (CFB) to a User and is busy = Deleted

• External Call to Agent, Agent has activated a call forward on no response (CFNR) to a User, User answer after timeout = Agent

• External call to Agent A, Agent A has activated a unconditional call forward (CFU) to Agent B = Agent B

• External Call to Agent A, Agent A has activated a call forward on busy (CFB) to Agent B and is busy = Agent B

• External Call to Agent A, Agent A has activated a call forward on no response (CFNR) to Agent B, Agent B answer after timeout = Agent A

Note: If Threat call recording is on a call can be marked to store from the calling or called agent. But if both parties are Agent, the called Agent has to dial the code for storing: if the caller dials the code the record will not be saved.

From version 11 on the generated pcap file have a different format. While in former versions the name of a pcap file was a unique single long number form version 11r1 on the ticket as two additional id, one is build form the serial number of the device and the other one if an increasing number. This new format is also generated when recording is done form directly the phone. The recorder can handle both formats automatically, no special setup is required.

We want to focus your attention on the reason of the new format. If for example the recording is done on the phone the phone will generate a new pcap file each time a new call is opened form the PBX point of view.

Example: Phone rings and the user answers, the recording starts with record 1. Then the user put the call on hold and call another extension, this generates record number 2. Then the phone returns to the first call and continuous talking that will be the 3td call. Of cause using the player you will see those 3 calls one after the other (using the user as filter). That this is one situation you recognize looking the reporting details displayed and if you select the 3 calls the player will play one after the other (switch on the loop key) and you listen the entire call in one shoot.

== Known Problems ==

===Open a ticket===

If you have a problem with the recording tool you have to open a ticket as usual. Describe your problem, but send us also the following information:

- Setup of your PBX (with standard password or tell us the password)

- Version of the reporting

- Attach all log and error files and the setup of the recorder. All those files are in the log folder (so zip the entire folder), you find the path and link to the folder in the recorder setup.

- Make some screenshots if possible.

- Open the reporting and do a query where the recorded conversations are in (if possible). Do an export in XML and attached it.

=== No CDR ticket after start-up ===

If a record is not found on the CF and there is no SOAP info about that (for example if you start the recording and there are old terminated calls) the recording checks if the reporting has a related record. If a record is found and it is an Agent involved the record is stored as usual, if no Agent is involved the record will be deleted.

But if there is a recording file found and in the recording there is no related record, the recorder cold simply deletes that record; but this could be fatal. For example the reporting could answer once bad, or the link between the reporting and the PBX is temporary down; in that cases the recording will be lost if simply deleted. Therefore the recorder waits in this situation and asks the reporting again after 2 hours. If even after 2 hours the reporting answer with no record found the file will be deleted (otherwise normally processed and stored or deleted as described before).

Note that the reporting is not aware about the health of the connection between PBX and the Reporting. If the recorder gets no answer from the reporting an alarm occurs and the reporting will not proceed with the storage. But the answer “no record found” is not a clear situation for the software. Therefor this situation has to be avoided and occurs for example if pcaps are recorded, but the users involved have no reporting while the recorder is down and starts up later. So the recorder will “find” pcap files but no reporting information.

During online operation this will not happen, because the SOAP driver will tell the recorder that a specific record has to be deleted, and so the recorder will not check the reporting. This is done even to speed up the recorder because the communication with the reporting is relatively slow. If for example there are many users doing a recording (because a bad setup or simply because a huge PBX) and there are only few users to record a huge amount of files are simply to delete without any further processing. Deleting of files is relatively fast during online operation while in case of startup and then recover historic records it becomes slow, and very slow if there are no CDR tickets. The online deleting of files is just “relatively fast” because the SOAP is very fast but the recorded file has to be closed before deleting. Trying to delete a not closed file will cause an error, if that happen the system after e while will recover, but it is not nice. On top there is no way on a CF to understand if a file is in use or not. Therefore the system will wait 2 seconds before deleting a file.

=== No CDR ticket online ===

There is even an unclear situation in online operation. Imagine that an Agent transmits no CDR information to the reporting (for example because there is no reporting license assigned to that user) or, because of a bad setup in the PBX, the ticket will not arrive to the reporting. A call of an Agent is terminated, the SOAP driver informs the upper layer of the software about that and now the recording ask the reporting about the CDR details. Note that the reporting is not down; the recorder can reach the reporting and get also answers (otherwise the REP alarm would be on). If after a detected call end of an Agent signaled by SOAP and a timeout of 5 seconds no CDR is in the reporting a garbage select routine is activated in the recorder software; this routine ask a second time after other 5 seconds the reporting. If even now the response is “no record found” the reporting waits for this call 2 hours. After 2 hours a third time the reporting is asked, if no record is found the pcap is deleted, otherwise normal processed.

If a record is waiting in the 2 hours timeout status in the field “status” the countdown proceed is shown, for example “P1443”, after 5 seconds “P1442” and so one (number*5/60 = time in minutes to zero).

To fix it just stop the recording, solve the problem if possible (if you are lucky for example the CDR data are in the PBX buffer and will be send to the reporting when connection is up again), if not save the Pcap file, at least it will not be deleted. Then delete the pcap file on the CF to avoid a slowdown of the entire system.

A simple but good idea is to enable the CDR on the recording trunk line, in this case “some information” for the call is retrieved all time and at least the system will not face that problem.

All described can be the result of a bad or erroneous setup, or the customer is aware of that and simply not interested in a good working application. So a “no record” answer could be a real alarm or not. Therefore in the setup that can be selected.

See recording setup, panel reporting, option “Alarm if no CDR ticket found”.

=== Asynchronous reporting/PBX date and time ===

PBX and reporting must have the same date and time. If not, the reporting will detect that and display error and warning messages about a possible manipulation in the files.

So check first the actual date and time of PBX and reporting.

IPVA: Remember that date can be set in the reporting in administration, General, Configure NTP server.

== Related Articles ==

[[Reference10:Player_Voice_Recording]]

[[Reference10:Voice_Recorder/Setup]]

[[Howto:Last_Call_Recording]]

[[Howto:Universal_Track_Recording_Tool]]

[[Howto:Integration_reporting_and_voice_recording]]

[[Howto:Soft-migration_%28looping_in_a_innovaphone_gateway%29_and_Voice_Recording]]

[[Howto:Player_over_http]]

[[Howto:Marking_a_record_in_Voicerecording]]

[[Howto:Voice_Recording_in_Master_Slave_scenarios]]

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

Reference11r1:PBX/Objects/Conference

2015-03-13T15:44:22Z

Nfinzel:

The PBX conference object manages conference rooms with announcements and PIN protection.

The conference calls themselves are connected by one or more ''conference servers (MCU)'' registered to this object as devices. If more than one conference server is used, the different media types of the calls can be split to the different servers. A innovaphone CONF interface can be registered to this object to provide audio conferences with application sharing.

== General Configuration ==

The information about general configuration options shared by all objects can be found at [[{{NAMESPACE}}:PBX/Objects]].

== Devices ==
; Hardware Id
: The hardware Id must match with a hardware Id of a device on the General page of the object (not the Gateway). The device is registered to this object and provides the conference service.
; innovaphone device
: This should be ticked if the MCU is an innovaphone device.
; Media Types
: If a media type is ticked, calls to the registration includes this media type.
; Number of channels
: The number of the available channels of the MCU device.
; MCU Room Numbers
: If the device isn't an innovaphone device and has severals rooms, the room numbers which are dialed can be configured here.
; Registration
: If a registration to this hardware Id exists, the IP address of the registrar is shown here.

== Options ==
; Announcement URL
: The URL where the announcements were saved. A '$type' within the URL is substituted for the announcement type string, e.g. ''<nowiki>http://127.0.0.1/webdav/conference/$type.$coder?coder=g722,g711u,g711a,g723,g729</nowiki>''. The announcement types are listed [[{{NAMESPACE}}:PBX/Objects/Conference/Announcement_types | here]].
; Extern Announcement Name/No: The conference object uses the internal HTTP interface, but announcements can also be provided by an external destination which name or number is to be configured here.
; Room number length
: If the room number length is zero, there is only one room available. If it isn't zero, static rooms can be configured and temporary rooms can be created with the operator.
; PIN
: If the room number length is zero, the PIN of the single conference room can be configured here. It can be empty or consists of four digits.
; Operator enabled
: If ticked, the operator is active. It can be reached if no room number is dialed.
; Trace
: If ticked, the trace of this PBX object is enabled.

== Rooms ==
Up to ''ten'' static rooms can be configured. If the room is called by the first member, the configured number of channels and all media types must be available otherwise the room isn't available. If the last member of a room leaves it, the reserved channels are released again.
A room is defined by:
; Room number
: The room number must be unique; it length depends on the room number length option.
; Number of channels
: The number of channels which must be available to open a room at dial-in. If this count of member is reached, the room is full and no further caller can take part.
; Media types
: If a media type is ticked, it is used for the call. If not all ticked media types are available at dial-in, the room can't be opened.
; PIN
: The room PIN can be empty or consists of four digits. The PIN can't be a part of the dialing number.

== Operator ==
If the operator is enabled, user can dial in and create ad-hoc rooms. The requested number of channels for new rooms must be available and are reserved till the last member leaves the room.
; Operator Number
: The number which must be dialed instead of an room number to start the operator. Room numbers mustn't match with this number; numbers of new ad-hoc rooms are checked again it.
; PIN
: The operator PIN can be empty or consists of four digits. The PIN can't be a part of the dialing number.
; Media Types for ad-hoc rooms
: The media types which are used for the ad-hoc rooms. The room is also created if not all media types are available, but at least the audio channels.
== Announcements ==
For the supported announcements, please refer to [[{{NAMESPACE}}:PBX/Objects/Conference/Announcement types]].

Howto:How to interpret SIP error codes returned by the innovaphone SIP stack

2015-03-11T15:35:11Z

Nfinzel:

How to interpret SIP error codes returned by the innovaphone SIP stack

==Applies To==
This information applies to

* all innovaphone devices

Build V6 and later

==More Information==

The SIP stack will return SIP Error-Response-Codes in various situations.

For trouble shooting, it is useful to know which error codes can be returned and why.

===Register message===

; 488 Not Acceptable Here :
Overlapping Transaction (e.g. the client sends a new Register although the previous one was not answered yet)

; 420 Bad Extension:
Unsupported extension (Require-Header)

; 400 Bad Request: Missing or incomplete From or To header in request

;403 Forbidden: From-URI and To-URI differ. This is not accepted as the so-called „3rd-Party-Registration“ is not supported.

;301 Moved Permanently or 302 Moved Temporarily: This is not an error. The client should retry the register with the new registrar provided along with the response. This is used in innovaphone multi-location PBX configurations.

;401 Unauthorized: There is password configured fort he affected user and the request contains no or an invalid password

;404 Not Found: The user is unknown (neither a PBX user nor a GWxx alias)

;503 Service Unavailable: The registration cannot take place. For example, the user is already registered and there is no password defined (only the first registration is possible w/o password) or there is no appropriate license available

===Invite message===
;302 Moved Temporarily: This is not an error. The requesting client SHOULD retry the request at the new address(es)given by the Contact header field.

;403 Forbidden: The calling client is not registered and there is no interface defined that allows such clients

;407 Proxy Authentication Required: There is a password defined for the user and the request came with no or invalid pasword

;482 Loop Detected: An incoming call is causing a call loop (as we have sent it ourselves)

;406 Not Acceptable: An incoming call appears which was initiated by ourselves but has different CSeq

;500 Internal Server Error: Out of resources (unlikely).

;415 Unsupported Media Type: There is no compatible audio coder available fort he call

;484 Address Incomplete: This is not an error. The number presented so far is incomplete (Overlap Dialing)

;486 Busy Here: Called Party busy

;404 Not Found: Called Party unknown (Unallocated (unassigned) number)

;480 Temporarily Unavailable: Called Party known, but currently not registered (No User responding).

;603 Decline: Called Party has rejected the call (Call rejected)

;503 Service Unavailable: Routing failed (No circuit/channel available from remote)

;503 Service Unavailable: Routing failed (Requested circuit/channel not available from remote)

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

Howto:Configure the innovaphone Voicemail

2015-03-11T08:03:08Z

Nfinzel:

The innovaphone voicemail (VM) is implemented as a PBX object.
An answering machine can be assigned to each PBX user.
The VM is script-driven and controlled by means of DTMF touchtones.
It features a built-in WebDAV client, enabling the VM to communicate to an external WebDAV server, which serves as the mass-storage for audio files, script files and user-directories.
The VM script and pre-recorded audio files are subject to be provided by innovaphone.
Message Waiting Indication (MWI) is supported.



==Applies To==
This information applies to

* innovaphone PBX, V6 and Higher

==More Information==

===System Requirements===
Voicemail license: The innovaphone voicemail requires licensing. The number of acquired voicemail licenses must be equal or greater than the number of PBX basic licenses.

WebDAV server, e.g.: Apache 2.x, IIS W2K, IIS W3K, or with V6 sr1 the compat flash drive (no external WebDAV server needed)

Innovaphone will provide you with an XML script, that represents the actual voicemail. In addition you will get a set of files with *.g711a, *.g711u and *.g729 extensions. These files contain the audio snippets and the menu prompts, that the voicemail requires.

==Installation, WebDAV==
A few preconditions are assumed as basis for the following few installation and configuration steps:

* The number of the VM object is 66.

* The number of a sample user test is 49.

* The IP address of the WebDAV server is 192.168.0.5.

* The root directory, that contains the VM script and the pre-recorded audio files is c:\Inetpub\webdav\vm\en which corresponds to the URL http://192.168.0.5/webdav/vm/.

* The file name of the voicemail XML script is vm.xml.

===Creating the Voicemail Object===
Proceed to Administration/PBX/Objects.
*Select Voicemail from the drop-down list and click on new.
*Enter Long Name, Name.
*Enter 66 as Number.
*Enter the Script URL as http://192.168.0.5/webdav/vm/vm.xml.
**'''Note:'''Meanwhile it is recommended to enter it as: http://192.168.0.5/webdav/vm/vm.xml?$_pbxfwd=true (see [[#URL Query String Variables]])

===Distributing the Voicemail Script and Pre-Recorded Audio Files===
The download section offers ZIP files and a Windows installation program. See [[#Download]] for how to find the download site.
* ZIP files
**Download the ZIP file for the language your are interested in (e.g. ''vm-de'', ''vm-en'', ...) from the ''apps'' package on the [http://download.innovaphone.com innovaphone download area].
**Un-ZIP the file. This step creates a language specific sub-directory that may be copied onto the CF-card.
* Windows installation program
**Download the installation program for the ''innovaphone voicemail'' from the [http://download.innovaphone.com innovaphone download area].
**Start the installer program (innovaphone-voicemail-install.exe).
**The installer will be asking for a target directory. Enter ''c:\Inetpub\webdav\vm\''. Now, the installer will copy all of the localized voicemail files into language specific sub-directories. The english files will remain under the absolute path ''c:\Inetpub\webdav\vm\en\''.

===Configuration===
Please note, that a user's VM number is the number of the VM object, that you assigned here, plus the user's number.

Example: If a user has the number 49 and the number of the VM object is 66, then the user's corresponding VM number will be 6649.

===IP Phone Configuration===
====V6, SR1: Recommended Configuration====
A user may wish to manually activate or deactivate a CFU diversion to his VM.
* Browse to the IP phone of the user 49:test:
* Proceed to ''Configuration/RegistrationX/Function Keys''.
* Select a free function key, choose ''Call Forwarding'' and click on ''new''.
* A new window will open. Enter ''AM-on'' under ''Idle State/Text''.
* Enter AM-off under ''Active State [1]/Text''.
* Enter ''6649'' into ''Active State [1]/Text/Always/Number''.
* Click on ''OK''.

An additional function key is required to present the MWI and to quick-dial the VM:
* Proceed to ''Configuration/RegistrationX/Function Keys''.
* Select a free function key, choose ''Message Waiting'' and click on new.
* A new window will open. Enter ''AM'' under ''Idle State/Text''.
* Select the ''letter'' icon under ''Active State/Icon''.
* If you desire, then choose ''LED/blink''.
* Enter ''6649'' into ''Message Center Account/Number''.
* Click on ''OK''.

====V6, SR2: Recommended Configuration====
The SR2 configuration adapts to mass-deployment requirements, in such that the set of required configuration parameters can be distributed identically among all affected phones.

A user may wish to manually activate or deactivate a CFU diversion to his VM.
* Browse to the IP phone of the user 49:test:
* Proceed to ''Configuration/RegistrationX/Function Keys''.
* Select a free function key, choose ''Call Forwarding'' and click on ''new''.
* A new window will open. Enter ''AM-on'' under ''Idle State/Text''.
* Enter ''AM-off'' under ''Active State [1]/Text''.
* Enter ''66'' into ''Active State [1]/Text/Always/Number''.
* Click on ''OK''.

An additional function key is required to present the MWI and to quick-dial the VM:
* Proceed to ''Configuration/RegistrationX/Function Keys''.
* Select a free function key, choose ''Message Waiting'' and click on new.
* A new window will open. Enter ''AM'' under ''Idle State/Text''.
* Select the letter ''icon'' under ''Active State/Icon''.
* If you desire, then choose ''LED/blink''.
* Enter ''66'' into ''Message Center Account/Number''.
* Activate the ''Append Own Number'' checkmark.
* Click on ''OK''.

====Deploying the MWI Function Key By An Update Script====
From on V6,SR2 the MWI key configuration can be designed to be applicable for all phones. The following excerpt shows how the resulting configuration line would look alike for our example.

mod cmd PHONE USER-UI/0 fkey-edit /id 0 /fkey_id 0 /fkey_type mwi /label mwi-off /icon letter /mwi.label mwi-on /mwi.icon letter-black /mwi.led blink /mwi.e164 66 /mwi.ext on /op OK

* ''/mwi.e164 66'' defines the MC number ''66''
* ''/mwi.ext on'' activates the ''Append Own Number'' checkmark

===Webserver Aspects===
WebDAV in Common: As stated above, WebDAV is required for the VM to work.

What is WebDAV? In its long form it reads "Web-based Distributed Authoring And Versioning" and is specified in RFC2518.
Technically is WebDAV a set of protocol extensions to the HTTP protocol.
These extensions allow for some file i/o operations,that aren't covered by HTTP:
*Renaming, moving, copying a file file.
*Properties: That is, information retrieval about a certain file. E.g. the file creation time.

===Webserver Authentication===
If HTTP Authentication is required, configure a triple of ''URL,User,Password'' underneath ''Configuration/General/HTTP-Client''.

In our example ''http://192.168.0.5/webdav/'' may be entered as ''URL''. Every URL that head-matches this URL and requires authentication will be authenticated with the user,password provided here.

===Apache Webserver 2.x===
The Apache supports WebDAV from on version 2.0 natively.

However, WebDAV must be enabled to be run. Please find the respective documentation page at apache.org under http://httpd.apache.org/docs/2.0/mod/mod_dav.html .

Test Environment: Our test environment was a RedHat Linux 8.x.
The configuration file for httpd resides under /etc/httpd/conf/httpd.conf .
The voicemail is located underneath /var/www/webdav/vm/.

Open httpd.conf with a text editor.
*Ensure the modules required for WebDAV are being loaded
<code apache>
LoadModule dav_module modules/mod_dav.so
LoadModule dav_fs_module modules/mod_dav_fs.so
</code>

*Ensure, that WebDAV is enabled and that an alias is being created for webdav
<code apache>
Dav On
Alias /webdav "/var/www/webdav"
</code>

*In our test environment we didn't restrict access to the webdav directory
<code apache>
Options Indexes MultiViews
Allow from all
</code>

An important aspect is the fact, that we had to apply chmod -R 766 to the /var/www/webdav directory. chmod -R 666 didn't suffice.

Without doing so, i.e. granting the read-/write-/execute-access, we received Forbidden responses when e.g. trying to read the filenames within a directory.

A potential delay source can be reverse DNS lookups. A webserver is trying to retrieve a DNS name for every source address it receives requests from. The drawback is, that every HTTP request is being delayed by the amount of time it takes to complete the reverse DNS lookup.

Within httpd.conf we therefore wrote ''HostNameLookups Off'', in order to avoid DNS requests for logging purposes.

Please note further that access restrictions with DNS names, instead of IP addresses, will
bypass this setting, i.e. will make the ''HostNameLookups Off'' -setting ineffective.

===Microsoft Internet Information Server (IIS), W2K===
As a testbed an IIS 5.0 was utilized on a Windows 2000 server. By default WebDAV is already enabled within IIS 5.0. However, no data is published.

*To publish data simply.
Create a new virtual directory webdav within the default website by means of the IIS Admin. Allow read, write and browse operations being executed on that directory and underneath.
Use the Windows Explorer to modify the security settings of the directory (and underneath) and set it to full access for everyone (It is left up to the Windows experts how to restrict this further).

===Microsoft Internet Information Server (IIS6), W2003 ===
In contrast to Windows 2000 Server, Windows Server 2003 does not come with WebDAV being already enabled. In addition File extensions with *.g711a, *.g711u and *.g729 must be configured as a new Mime-Type. You must enable WebDAV from within the IIS Admin first. Files with the extension *.g711a, *.g711u and *.g729 will not be returned.

*You must add *.g711a, *.g711u *.g729 as a Mime-Type, otherwise the audio files won't be accessible.
Pls. see: MS KB article Q326965 http://support.microsoft.com/kb/326965/en-us ,respectively http://support.microsoft.com/kb/326965/de-de for how to do this.

Browse to http://192.168.0.5/webdav/vm/ and try to download a g711a-file and a g729-file from within your browser. This step will prove, that the Mime-Types were successfully added.

'''Note:''' After the new Mime-Types were added an IIS6 restart seemed to be a MUST.

===Microsoft Internet Information server (IIS7)===
Two possibilities for authentication are available.

====HTTPS With Basic Authentication====
IIS7 does NOT support HTTP ''Basic Authentication'' without HTTPS/TLS. Therefore it is mandatory to run WebDAV towards the IIS7 on HTTPS and not on HTTP.
*Within the Voicemail object a "<nowiki>https://..</nowiki>"-URL must be configured.
*Under ''General/HTTP/Client'' a user/password tupel must be configured for the "<nowiki>https://..</nowiki>"-URL.
*Within the IIS Admin it must be ensured that ''Basic Authentication'' is allowed.
*Try calling the voicemail object. The request for the voicemail script is going to fail.
*Watch out for a rejected certificate under ''General/Certificates'' and trust that certificate.
*Try calling again the voicemail object. This time the request for the voicemail script should be succeeding.

====HTTP With Digest Authentication====
{{FIXME|reason="Information is vague. Practical confirmation needed. Detailing needed."}}
A user account must be configured within the Active Directory to allow it's password be cached. This is simply because the digest authentication needs to derive a challenge value from a password. That user account/password tupel must in turn be utilized for the innovaphone HTTP client.

We have had reports that digest authentication does not work with some IIS7 servers. Evaluation has shown that these servers do require <code>MD5-sess</code> instead of <code>MD5</code> as endpoint authentication type.

Microsoft states ''For security reasons, Windows-based digest authentication only supports MD5-sess encryption over domain controllers that are running under Windows Server 2003.'' [http://technet.microsoft.com/en-us/library/ms191264.aspx]. This suggests that authenticated HTTP access from an innovaphone box to an IIS7 using a domain account may not work at all as long as we do not support MD5-sess (which we don't do as of this writing (January 2012)). A possible fix may be to use a local server account (although this has not been tested).

===Microsoft Internet Information server (IIS7.5)===
Despite an allegedly configured server role ''WebDAV Publishing'' a WebDAV-connect wasn't possible until adding a ''WebDAV Authoring Rule'' by means of the IIS Admin.
*'''Access for''' Entire Content
*'''Grant Conten Access For''' All Users
*'''Rights''' Read, Source, Write

Before administrating this step a ''PROPFIND'' was always honored by a ''405/Method Not Allowed''.

===innovaphone own WebDav Server (Compact flash card slot)===
Please see [[#Installation, CompactFlash Card|Installation, CompactFlash Card]] below.

===Testing WebDAV Access===
From within the Windows Explorer go to Tools/Map Network Drive.
*Select Web folder or FTP site.
*Enter the URL http://192.168.0.5/webdav/ and proceed.

Now you may test whether you can read files, write files, delete files, create directories.

===User-Related Files And Directories===
Our sample user has the number 49 and the name test. When this user calls his box 6649 for the first time, the VM will create a directory for him and underneath a pair of additional directories. The new directories for the user test are:

*…/webdav/vm/test/. New voicemails will be copied here.
*…/webdav/vm/test/personal. The personal greeting message resides here.
*…/webdav/vm/test/store. When a message is stored, it is copied into this location.

If the directory creation fails, the call to the VM will be forcedly disconnected.

===PIN Administration===
Initially, there is a default PIN active. When being asked for a PIN, enter 8765.

The PIN can be changed by means of menu option 4.

The PIN can be reset administratively to the default by just deleting ''.../personal/pin.txt'' within a user's directory.

===URL Query String Variables===

URL Query String Variables are generally passed on to a script.

The following variables control the script's behaviour and may be applied within the configured script-URL alike: http://192.168.0.5/webdav/vm/vm.xml?$_nopin=true.

Multiple variables can be combined by an ampersand (&) alike: http://192.168.0.5/webdav/vm/vm.xml?$_nopin=true&$_pbxcoder=g711a.

* $_nopin. Controls, whether a PIN must be entered.
**true: Voicemail owner doesn't need to enter a PIN when calling from his extension.
**false (default): A PIN must be entered
(Note: A PIN must always be entered when calling from "foreign" extensions)

* $_initdelay: Controls, whether an initial silence prompt is going to be played to a caller. From on script version ['''vm.xml 60096'''].
** 0(default): No silence prompt will be played.
** a value greater than 0: A silence prompt of ''N'' seconds is going to be played. For hosting scenarios the recommended value is '1'.

* $_pbxcoder. Allows to restrain the offered coder list, when executing <pbx-prompt> for files with "*.$coder" extensions.
** The internal default is: $_pbxcoder=g729,g711a,g711u,g723

* $_pbxfwd
** true: diversions will be executed on <pbx-fwd>
** false (default): diversions won't be executed on <pbx-fwd>

* $_pbxmwidir. Allows to configure a parent directory for all user sub-directories and for all MWI operations. As default there is no such directory active.

* $_pbxremhold
** true (default): Rules whether caller will be sent a REMOTE-HOLD while executing <pbx-fwd>.
** false: No REMOTE-HOLD is sent

* $_noctl (from on v8hotfix8)
**true: Control-calls (calls without media) will be rejected
**false (default): no rejection

* $_divconn (from on v9hotfix17)
**true: Auto-Connect for calls being recognized as diverted or transferred calls
***Note: Until V11r1sr2 the former default was ''true''
**false(default): No automated connection for diverted/transferred calls.
'''Note:''' It is recommended to configure '''$_divconn=false''' in scenarios with remote media streaming(via an active registration at the VM object).

* $_trace, decimal number: Controls verbosity of tracing outputs. The following values can be added. Everything can be traced by simply entering 255 (i.e. ''$_trace=255'').
** 1: errors, 2: interpreter, 4: parsing, 8: code, 16: store operations, 32: http operations (during <exec>), 64: <debug> statements, 128: webmedia

*$_leg2tweak (from on v9hotfix21) controls <pbx-getcallinfo out-leg2=".."/>
**true(default): set leg2 to <ext-nr> from <vm-nr>+<ext-nr>
**false: set leg2 according to received divertingInfoLeg2 facility

*$_trailhash (from on v9hotfix21) controls <pbx-getcallinfo out-cdpn=".."/>
**true: pass trailing (en-bloc) '#' into cdpn
**false(default): don't pass trailing (en-bloc) '#' into cdpn

* $_pbxfwdrel controls <pbx-fwd> (from on v10sr5)
**conn: release all interpreter resources after a successful connect. No further scripting affects the call.
**imm: release all interpreter resources immediately on the execution of the <pbx-fwd> statement. No further scripting affects the call.
**false(default): No tweaks apply. The script interpreter remains active.

==Installation, CompactFlash Card==
Instead of using a WebDAV server you may want to use the local CompactFlash card as mass storage device. This section outlines how this can be accomplished.
=== Installing the Voicemail on a CompactFlash Card ===
Please see the article [[Howto:Installing the voicemail/music on hold on a compact flash card|Howto:Installing the voicemail on a compact flash card]].

The aforementioned configuration scenario, within the above chapter: [[#Installation, WebDAV|Installation, WebDav]], does also apply for an installation on a CompactFlash card. Please, refer to that chapter if you look for informations on how to generally configure a basic voicemail scenario, including the affected ip phone configuration.

==Advanced Configuration==
=== Maximum Message Length ===
By default, voicemail messages are limited to 50 seconds each.
To change the maximum length (e.g. to 5 minutes), you have to change the following code line

<pbx-record url="$vm" sec="50"/>

to

<pbx-record url="$vm" sec="300"/>

=== Change Filename of the Recorded Messages of Voicemail ===

By default the vm.xml records the voice messages in the CF at UserBox with an Unique Name, type of GUID + Extension and this is also what is send to the user email when we set that option. Example : 2110d5f4e909d311baab0090332901b6-202.wav

We can change this filename format by editing the vm.xml approx. line 63:

replace

<store-getnew root="$sub" out-url="$vm"/>
<lib-strcat string="$vm" string2="-" out-string="$vm" />
<lib-strcat string="$vm" string2="$cgpn" out-string="$vm" />
<lib-strcat string="$vm" string2=".g711a" out-string="$vm" />

with

<store-getstat root="" name="NULL" out-wday="$wday" out-mday="$mday" out-mon="$mon" out-year="$year" out-hour="$hour" out-min="$min"/>
<store-get root="$sub" name="date-" out-url="$vm"/>
<lib-strcat string="$vm" string2="$year" out-string="$vm" />
<lib-strcat string="$vm" string2="-" out-string="$vm" />
<lib-strcat string="$vm" string2="$mon" out-string="$vm" />
<lib-strcat string="$vm" string2="-" out-string="$vm" />
<lib-strcat string="$vm" string2="$mday" out-string="$vm" />
<lib-strcat string="$vm" string2="-time-" out-string="$vm" />
<lib-strcat string="$vm" string2="$hour" out-string="$vm" />
<lib-strcat string="$vm" string2="-" out-string="$vm" />
<lib-strcat string="$vm" string2="$min" out-string="$vm" />
<lib-strcat string="$vm" string2="-number-" out-string="$vm" />
<lib-strcat string="$vm" string2="$cgpn" out-string="$vm" />
<lib-strcat string="$vm" string2=".g711a" out-string="$vm" />

Doing this will obtain a filename with Date, Hour, Number and CGPN.

===Leave Message to the VoiceMail Box of the original called User===
By default the VoiceMail stores the voice message to the Mailbox of the Object performing diversion to the VoiceMail. E.g. if "User A" creates a call forward to the VoiceMail, the Mailbox is used to store the message is from "User A". In case "User A" creates a call forward to a Waiting Queue or Call Broadcast, and than from Call Broadcast Group to the VoiceMail, the message will be stored in the Mailbox of the Call Broadcast Group.

To change this behaviour and to store the Message always to the Mailbox of the originally called User, change the vm.xml as following:

search the line:

<code xml>
<pbx-getcallinfo out-cgpn="$cgpn" out-cdpn="$cdpn" out-leg2="$leg2"/>
</code>

and replace them with the following

<code xml>
<pbx-getcallinfo out-cgpn="$cgpn" out-cdpn="$cdpn" out-leg2="$leg2" out-leg2-orig="$leg3"/>
</code>

add the following code after the line

<code xml>
<switch var="$leg3">
<case not-equal="">
<assign out="$leg2" value="$leg3"/>
</case>
</switch>
</code>

===Sending of additional MWIs===
* [[Howto:How To Send Additional MWIs within a PBX|How To Send Additional MWIs within a PBX]]
The article deals with the question how a single voicemail box can be shared among a few users.
===Custom Personal Announcement===
* [[Howto:Deploy A Custom Personal Announcement For the innovaphone Voicemail|Deploy A Custom Personal Announcement For the innovaphone Voicemail]]
Explains where to copy an externally generated personal announcement file.
===A Simple Recording Solution On-Top of The innovaphone Voicemail===
* [[Howto:A Simple Recording Solution On-Top of The innovaphone Voicemail|A Simple Recording Solution On-Top of The innovaphone Voicemail]]
This article explains how a simple recording solution could be set up on-top of an innovaphone Voicemail.
===Send Email MWI Notification From The innovaphone Voicemail===
*[[Howto:Send Email MWI Notification From The innovaphone Voicemail|Send Email MWI Notification From The innovaphone Voicemail]]
This functionality is available from on SR2 and allows to send MWI notifications by email.

==Quick Reference For innovaphone Voicemail==
* [[Howto:Quick Reference For innovaphone Voicemail|Quick Reference For innovaphone Voicemail]]
The article outlines the menu structure and provides a few operational hints from a user's perspective.

==Known Problems==
The VM makes use of V6’s media negotiation capabilities.
This is why V5 endpoints are not supported.

*[[Support:Voicemail Calls Hanging Around In PBX Call Monitor|Support:Voicemail Calls Hanging Around In PBX Call Monitor]]
*[[Support:Voicemail: Voicebox Not Configurable With "Send Number" set|Support: Voicemail: Voicebox Not Configurable With "Send Number" set]]
* When the voicebox is created upon the first call to the users voicemail, you must not have the ''Send Number'' property configured in the calling user object. Otherwise, the voicebox will be created for the wrong number
* [[Support:Voicemail Fails With "Missing Voicemail License!"|Support:Voicemail Fails With "Missing Voicemail License!"]]
*[[Support:Voicemail Fails With "Authentication Required"|Support:Voicemail Fails With "Authentication Required"]]
*[[Support:Webdav_Access_Slow_From_Windows_7_/_Vista|Support:Webdav Access Slow From Windows 7 /Vista]]

== Related Articles ==

===Voicemail Installation===

* [[Howto:How to setup an V6 IP Phone for innovaphone voicemail usage]]
* [[Howto:Send Email MWI Notification From The innovaphone Voicemail]]
* [[Howto:Quick Reference For innovaphone Voicemail]]
* [[Howto:Forward your Mobile's Mailbox to your innovaphone Voicemail]]

===Voicemail on Compact Flash===

* [[Howto:General information for compact flash cards]]
* [[Howto:Installing the voicemail/music on hold on a compact flash card]]

===Voicemail Customising===

* [[Howto:Deploy A Custom Personal Announcement For the innovaphone Voicemail]]
*[[Howto:Does innovaphone voicemail support multiple announcements?]]
* [[Howto:How To Send Additional MWIs within a PBX]]
*[[Howto:Send Email from the innovaphone Voicemail without saving data on the CF]]
*[[Howto:Localize Voice Mail Messages]]

===Voicemail Scripting===

*[[Howto:Implement a simple caller notification]]
*[[Howto:Getting started with your own PBX voicemail script]]
*[[Howto:Debug_your_own_PBX_voicemail_script]]
*[[Howto:A Simple Recording Solution On-Top of The innovaphone Voicemail]]
*[[Howto:Voicemail Scripting And Projektcode, PIN, Auth Code]]
*[[Howto:Simple ACD with Voicemail XML Script]]
*[[Howto:Control Call Forward with Voicemail XML Script]]

== Download ==
The voicemail product can currently be found on the [http://download.innovaphone.com/ice/6.00/#apps apps section] of the innovaphone download site. This product is suitable for PBX firmware ''versions 6 and up''.

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

Howto:Configure the innovaphone Voicemail

2015-03-11T07:37:54Z

Nfinzel:

The innovaphone voicemail (VM) is implemented as a PBX object.
An answering machine can be assigned to each PBX user.
The VM is script-driven and controlled by means of DTMF touchtones.
It features a built-in WebDAV client, enabling the VM to communicate to an external WebDAV server, which serves as the mass-storage for audio files, script files and user-directories.
The VM script and pre-recorded audio files are subject to be provided by innovaphone.
Message Waiting Indication (MWI) is supported.



==Applies To==
This information applies to

* innovaphone PBX, V6 and Higher

==More Information==

===System Requirements===
Voicemail license: The innovaphone voicemail requires licensing. The number of acquired voicemail licenses must be equal or greater than the number of PBX basic licenses.

WebDAV server, e.g.: Apache 2.x, IIS W2K, IIS W3K, or with V6 sr1 the compat flash drive (no external WebDAV server needed)

Innovaphone will provide you with an XML script, that represents the actual voicemail. In addition you will get a set of files with *.g711a, *.g711u and *.g729 extensions. These files contain the audio snippets and the menu prompts, that the voicemail requires.

==Installation, WebDAV==
A few preconditions are assumed as basis for the following few installation and configuration steps:

* The number of the VM object is 66.

* The number of a sample user test is 49.

* The IP address of the WebDAV server is 192.168.0.5.

* The root directory, that contains the VM script and the pre-recorded audio files is c:\Inetpub\webdav\vm\en which corresponds to the URL http://192.168.0.5/webdav/vm/.

* The file name of the voicemail XML script is vm.xml.

===Creating the Voicemail Object===
Proceed to Administration/PBX/Objects.
*Select Voicemail from the drop-down list and click on new.
*Enter Long Name, Name.
*Enter 66 as Number.
*Enter the Script URL as http://192.168.0.5/webdav/vm/vm.xml.
**'''Note:'''Meanwhile it is recommended to enter it as: http://192.168.0.5/webdav/vm/vm.xml?$_pbxfwd=true (see [[#URL Query String Variables]])

===Distributing the Voicemail Script and Pre-Recorded Audio Files===
The download section offers ZIP files and a Windows installation program. See [[#Download]] for how to find the download site.
* ZIP files
**Download the ZIP file for the language your are interested in (e.g. ''vm-de'', ''vm-en'', ...) from the ''apps'' package on the [http://download.innovaphone.com innovaphone download area].
**Un-ZIP the file. This step creates a language specific sub-directory that may be copied onto the CF-card.
* Windows installation program
**Download the installation program for the ''innovaphone voicemail'' from the [http://download.innovaphone.com innovaphone download area].
**Start the installer program (innovaphone-voicemail-install.exe).
**The installer will be asking for a target directory. Enter ''c:\Inetpub\webdav\vm\''. Now, the installer will copy all of the localized voicemail files into language specific sub-directories. The english files will remain under the absolute path ''c:\Inetpub\webdav\vm\en\''.

===Configuration===
Please note, that a user's VM number is the number of the VM object, that you assigned here, plus the user's number.

Example: If a user has the number 49 and the number of the VM object is 66, then the user's corresponding VM number will be 6649.

===IP Phone Configuration===
====V6, SR1: Recommended Configuration====
A user may wish to manually activate or deactivate a CFU diversion to his VM.
* Browse to the IP phone of the user 49:test:
* Proceed to ''Configuration/RegistrationX/Function Keys''.
* Select a free function key, choose ''Call Forwarding'' and click on ''new''.
* A new window will open. Enter ''AM-on'' under ''Idle State/Text''.
* Enter AM-off under ''Active State [1]/Text''.
* Enter ''6649'' into ''Active State [1]/Text/Always/Number''.
* Click on ''OK''.

An additional function key is required to present the MWI and to quick-dial the VM:
* Proceed to ''Configuration/RegistrationX/Function Keys''.
* Select a free function key, choose ''Message Waiting'' and click on new.
* A new window will open. Enter ''AM'' under ''Idle State/Text''.
* Select the ''letter'' icon under ''Active State/Icon''.
* If you desire, then choose ''LED/blink''.
* Enter ''6649'' into ''Message Center Account/Number''.
* Click on ''OK''.

====V6, SR2: Recommended Configuration====
The SR2 configuration adapts to mass-deployment requirements, in such that the set of required configuration parameters can be distributed identically among all affected phones.

A user may wish to manually activate or deactivate a CFU diversion to his VM.
* Browse to the IP phone of the user 49:test:
* Proceed to ''Configuration/RegistrationX/Function Keys''.
* Select a free function key, choose ''Call Forwarding'' and click on ''new''.
* A new window will open. Enter ''AM-on'' under ''Idle State/Text''.
* Enter ''AM-off'' under ''Active State [1]/Text''.
* Enter ''66'' into ''Active State [1]/Text/Always/Number''.
* Click on ''OK''.

An additional function key is required to present the MWI and to quick-dial the VM:
* Proceed to ''Configuration/RegistrationX/Function Keys''.
* Select a free function key, choose ''Message Waiting'' and click on new.
* A new window will open. Enter ''AM'' under ''Idle State/Text''.
* Select the letter ''icon'' under ''Active State/Icon''.
* If you desire, then choose ''LED/blink''.
* Enter ''66'' into ''Message Center Account/Number''.
* Activate the ''Append Own Number'' checkmark.
* Click on ''OK''.

====Deploying the MWI Function Key By An Update Script====
From on V6,SR2 the MWI key configuration can be designed to be applicable for all phones. The following excerpt shows how the resulting configuration line would look alike for our example.

mod cmd PHONE USER-UI/0 fkey-edit /id 0 /fkey_id 0 /fkey_type mwi /label mwi-off /icon letter /mwi.label mwi-on /mwi.icon letter-black /mwi.led blink /mwi.e164 66 /mwi.ext on /op OK

* ''/mwi.e164 66'' defines the MC number ''66''
* ''/mwi.ext on'' activates the ''Append Own Number'' checkmark

===Webserver Aspects===
WebDAV in Common: As stated above, WebDAV is required for the VM to work.

What is WebDAV? In its long form it reads "Web-based Distributed Authoring And Versioning" and is specified in RFC2518.
Technically is WebDAV a set of protocol extensions to the HTTP protocol.
These extensions allow for some file i/o operations,that aren't covered by HTTP:
*Renaming, moving, copying a file file.
*Properties: That is, information retrieval about a certain file. E.g. the file creation time.

===Webserver Authentication===
If HTTP Authentication is required, configure a triple of ''URL,User,Password'' underneath ''Configuration/General/HTTP-Client''.

In our example ''http://192.168.0.5/webdav/'' may be entered as ''URL''. Every URL that head-matches this URL and requires authentication will be authenticated with the user,password provided here.

===Apache Webserver 2.x===
The Apache supports WebDAV from on version 2.0 natively.

However, WebDAV must be enabled to be run. Please find the respective documentation page at apache.org under http://httpd.apache.org/docs/2.0/mod/mod_dav.html .

Test Environment: Our test environment was a RedHat Linux 8.x.
The configuration file for httpd resides under /etc/httpd/conf/httpd.conf .
The voicemail is located underneath /var/www/webdav/vm/.

Open httpd.conf with a text editor.
*Ensure the modules required for WebDAV are being loaded
<code apache>
LoadModule dav_module modules/mod_dav.so
LoadModule dav_fs_module modules/mod_dav_fs.so
</code>

*Ensure, that WebDAV is enabled and that an alias is being created for webdav
<code apache>
Dav On
Alias /webdav "/var/www/webdav"
</code>

*In our test environment we didn't restrict access to the webdav directory
<code apache>
Options Indexes MultiViews
Allow from all
</code>

An important aspect is the fact, that we had to apply chmod -R 766 to the /var/www/webdav directory. chmod -R 666 didn't suffice.

Without doing so, i.e. granting the read-/write-/execute-access, we received Forbidden responses when e.g. trying to read the filenames within a directory.

A potential delay source can be reverse DNS lookups. A webserver is trying to retrieve a DNS name for every source address it receives requests from. The drawback is, that every HTTP request is being delayed by the amount of time it takes to complete the reverse DNS lookup.

Within httpd.conf we therefore wrote ''HostNameLookups Off'', in order to avoid DNS requests for logging purposes.

Please note further that access restrictions with DNS names, instead of IP addresses, will
bypass this setting, i.e. will make the ''HostNameLookups Off'' -setting ineffective.

===Microsoft Internet Information Server (IIS), W2K===
As a testbed an IIS 5.0 was utilized on a Windows 2000 server. By default WebDAV is already enabled within IIS 5.0. However, no data is published.

*To publish data simply.
Create a new virtual directory webdav within the default website by means of the IIS Admin. Allow read, write and browse operations being executed on that directory and underneath.
Use the Windows Explorer to modify the security settings of the directory (and underneath) and set it to full access for everyone (It is left up to the Windows experts how to restrict this further).

===Microsoft Internet Information Server (IIS6), W2003 ===
In contrast to Windows 2000 Server, Windows Server 2003 does not come with WebDAV being already enabled. In addition File extensions with *.g711a, *.g711u and *.g729 must be configured as a new Mime-Type. You must enable WebDAV from within the IIS Admin first. Files with the extension *.g711a, *.g711u and *.g729 will not be returned.

*You must add *.g711a, *.g711u *.g729 as a Mime-Type, otherwise the audio files won't be accessible.
Pls. see: MS KB article Q326965 http://support.microsoft.com/kb/326965/en-us ,respectively http://support.microsoft.com/kb/326965/de-de for how to do this.

Browse to http://192.168.0.5/webdav/vm/ and try to download a g711a-file and a g729-file from within your browser. This step will prove, that the Mime-Types were successfully added.

'''Note:''' After the new Mime-Types were added an IIS6 restart seemed to be a MUST.

===Microsoft Internet Information server (IIS7)===
Two possibilities for authentication are available.

====HTTPS With Basic Authentication====
IIS7 does NOT support HTTP ''Basic Authentication'' without HTTPS/TLS. Therefore it is mandatory to run WebDAV towards the IIS7 on HTTPS and not on HTTP.
*Within the Voicemail object a "<nowiki>https://..</nowiki>"-URL must be configured.
*Under ''General/HTTP/Client'' a user/password tupel must be configured for the "<nowiki>https://..</nowiki>"-URL.
*Within the IIS Admin it must be ensured that ''Basic Authentication'' is allowed.
*Try calling the voicemail object. The request for the voicemail script is going to fail.
*Watch out for a rejected certificate under ''General/Certificates'' and trust that certificate.
*Try calling again the voicemail object. This time the request for the voicemail script should be succeeding.

====HTTP With Digest Authentication====
{{FIXME|reason="Information is vague. Practical confirmation needed. Detailing needed."}}
A user account must be configured within the Active Directory to allow it's password be cached. This is simply because the digest authentication needs to derive a challenge value from a password. That user account/password tupel must in turn be utilized for the innovaphone HTTP client.

We have had reports that digest authentication does not work with some IIS7 servers. Evaluation has shown that these servers do require <code>MD5-sess</code> instead of <code>MD5</code> as endpoint authentication type.

Microsoft states ''For security reasons, Windows-based digest authentication only supports MD5-sess encryption over domain controllers that are running under Windows Server 2003.'' [http://technet.microsoft.com/en-us/library/ms191264.aspx]. This suggests that authenticated HTTP access from an innovaphone box to an IIS7 using a domain account may not work at all as long as we do not support MD5-sess (which we don't do as of this writing (January 2012)). A possible fix may be to use a local server account (although this has not been tested).

===Microsoft Internet Information server (IIS7.5)===
Despite an allegedly configured server role ''WebDAV Publishing'' a WebDAV-connect wasn't possible until adding a ''WebDAV Authoring Rule'' by means of the IIS Admin.
*'''Access for''' Entire Content
*'''Grant Conten Access For''' All Users
*'''Rights''' Read, Source, Write

Before administrating this step a ''PROPFIND'' was always honored by a ''405/Method Not Allowed''.

===innovaphone own WebDav Server (Compact flash card slot)===
Please see [[#Installation, CompactFlash Card|Installation, CompactFlash Card]] below.

===Testing WebDAV Access===
From within the Windows Explorer go to Tools/Map Network Drive.
*Select Web folder or FTP site.
*Enter the URL http://192.168.0.5/webdav/ and proceed.

Now you may test whether you can read files, write files, delete files, create directories.

===User-Related Files And Directories===
Our sample user has the number 49 and the name test. When this user calls his box 6649 for the first time, the VM will create a directory for him and underneath a pair of additional directories. The new directories for the user test are:

*…/webdav/vm/test/. New voicemails will be copied here.
*…/webdav/vm/test/personal. The personal greeting message resides here.
*…/webdav/vm/test/store. When a message is stored, it is copied into this location.

If the directory creation fails, the call to the VM will be forcedly disconnected.

===PIN Administration===
Initially, there is a default PIN active. When being asked for a PIN, enter 8765.

The PIN can be changed by means of menu option 4.

The PIN can be reset administratively to the default by just deleting ''.../personal/pin.txt'' within a user's directory.

===URL Query String Variables===

URL Query String Variables are generally passed on to a script.

The following variables control the script's behaviour and may be applied within the configured script-URL alike: http://192.168.0.5/webdav/vm/vm.xml?$_nopin=true.

Multiple variables can be combined by an ampersand (&) alike: http://192.168.0.5/webdav/vm/vm.xml?$_nopin=true&$_pbxcoder=g711a.

* $_nopin. Controls, whether a PIN must be entered.
**true: Voicemail owner doesn't need to enter a PIN when calling from his extension.
**false (default): A PIN must be entered
(Note: A PIN must always be entered when calling from "foreign" extensions)

* $_initdelay: Controls, whether an initial silence prompt is going to be played to a caller. From on script version ['''vm.xml 60096'''].
** 0(default): No silence prompt will be played.
** a value greater than 0: A silence prompt of ''N'' seconds is going to be played. For hosting scenarios the recommended value is '1'.

* $_pbxcoder. Allows to restrain the offered coder list, when executing <pbx-prompt> for files with "*.$coder" extensions.
** The internal default is: $_pbxcoder=g729,g711a,g711u,g723

* $_pbxfwd
** true: diversions will be executed on <pbx-fwd>
** false (default): diversions won't be executed on <pbx-fwd>

* $_pbxmwidir. Allows to configure a parent directory for all user sub-directories and for all MWI operations. As default there is no such directory active.

* $_pbxremhold
** true (default): Rules whether caller will be sent a REMOTE-HOLD while executing <pbx-fwd>.
** false: No REMOTE-HOLD is sent

* $_noctl (from on v8hotfix8)
**true: Control-calls (calls without media) will be rejected
**false (default): no rejection

* $_divconn (from on v9hotfix17)
**true: Auto-Connect for calls being recognized as diverted or transferred calls
***Note: Until V11r1sr2 the former default was ''true''
**false(default): No automated connection for diverted/transferred calls.
'''Note:''' It is recommended to configure '''$_divconn=false''' in scenarios with remote media streaming(via an active registration at the VM object).

* $_trace, decimal number: Controls verbosity of tracing outputs. The following values can be added. Everything can be traced by simply entering 255 (i.e. ''$_trace=255'').
** 1: errors, 2: interpreter, 4: parsing, 8: code, 16: store operations, 32: http operations (during <exec>), 64: <debug> statements, 128: webmedia

*$_leg2tweak (from on v9hotfix21) controls <pbx-getcallinfo out-leg2=".."/>
**true(default): set leg2 to <ext-nr> from <vm-nr>+<ext-nr>
**false: set leg2 according to received divertingInfoLeg2 facility

*$_trailhash (from on v9hotfix21) controls <pbx-getcallinfo out-cdpn=".."/>
**true: pass trailing (en-bloc) '#' into cdpn
**false(default): don't pass trailing (en-bloc) '#' into cdpn

* $_pbxfwdrel controls <pbx-fwd> (from on v10sr5)
**conn: release all interpreter resources after a successful connect. No further scripting affects the call.
**imm: release all interpreter resources immediately on the execution of the <pbx-fwd> statement. No further scripting affects the call.
**false(default): No tweaks apply. The script interpreter remains active.

==Installation, CompactFlash Card==
Instead of using a WebDAV server you may want to use the local CompactFlash card as mass storage device. This section outlines how this can be accomplished.
=== Installing the Voicemail on a CompactFlash Card ===
Please see the article [[Howto:Installing the voicemail/music on hold on a compact flash card|Howto:Installing the voicemail on a compact flash card]].

The aforementioned configuration scenario, within the above chapter: [[#Installation, WebDAV|Installation, WebDav]], does also apply for an installation on a CompactFlash card. Please, refer to that chapter if you look for informations on how to generally configure a basic voicemail scenario, including the affected ip phone configuration.

==Advanced Configuration==
=== Maximum Message Length ===
By default, voicemail messages are limited to 50 seconds each.
To change the maximum length (e.g. to 5 minutes), you have to change the following code line

<pbx-record url="$vm" sec="50"/>

to

<pbx-record url="$vm" sec="300"/>

=== Change Filename of the Recorded Messages of Voicemail ===

By default the vm.xml records the voice messages in the CF at UserBox with an Unique Name, type of GUID + Extension and this is also what is send to the user email when we set that option. Example : 2110d5f4e909d311baab0090332901b6-202.wav

We can change this filename format by editing the vm.xml approx. line 63:

replace

<store-getnew root="$sub" out-url="$vm"/>
<lib-strcat string="$vm" string2="-" out-string="$vm" />
<lib-strcat string="$vm" string2="$cgpn" out-string="$vm" />
<lib-strcat string="$vm" string2=".g711a" out-string="$vm" />

with

<store-getstat root="" name="NULL" out-wday="$wday" out-mday="$mday" out-mon="$mon" out-year="$year" out-hour="$hour" out-min="$min"/>
<store-get root="$sub" name="date-" out-url="$vm"/>
<lib-strcat string="$vm" string2="$year" out-string="$vm" />
<lib-strcat string="$vm" string2="-" out-string="$vm" />
<lib-strcat string="$vm" string2="$mon" out-string="$vm" />
<lib-strcat string="$vm" string2="-" out-string="$vm" />
<lib-strcat string="$vm" string2="$mday" out-string="$vm" />
<lib-strcat string="$vm" string2="-time-" out-string="$vm" />
<lib-strcat string="$vm" string2="$hour" out-string="$vm" />
<lib-strcat string="$vm" string2="-" out-string="$vm" />
<lib-strcat string="$vm" string2="$min" out-string="$vm" />
<lib-strcat string="$vm" string2="-number-" out-string="$vm" />
<lib-strcat string="$vm" string2="$cgpn" out-string="$vm" />
<lib-strcat string="$vm" string2=".g711a" out-string="$vm" />

Doing this will obtain a filename with Date, Hour, Number and CGPN.

===Leave Message to the VoiceMail Box of the original called User===
By default the VoiceMail stores the voice message to the Mailbox of the Object performing diversion to the VoiceMail. E.g. if "User A" creates a call forward to the VoiceMail, the Mailbox is used to store the message is from "User A". In case "User A" creates a call forward to a Waiting Queue or Call Broadcast, and than from Call Broadcast Group to the VoiceMail, the message will be stored in the Mailbox of the Call Broadcast Group.

To change this behaviour and to store the Message always to the Mailbox of the originally called User, change the vm.xml as following:

search the line:

<code xml>
<pbx-getcallinfo out-cgpn="$cgpn" out-leg2="$leg2" out-cdpn="$cdpn"/>
</code>

and replace them with the following

<code xml>
<pbx-getcallinfo out-cgpn="$cgpn" out-cdpn="$cdpn" out-leg2="$leg2" out-leg2-orig="$leg3"/>
</code>

add the following code after the line

<code xml>
<switch var="$leg3">
<case not-equal="">
<assign out="$leg2" value="$leg3"/>
</case>
</switch>
</code>

===Sending of additional MWIs===
* [[Howto:How To Send Additional MWIs within a PBX|How To Send Additional MWIs within a PBX]]
The article deals with the question how a single voicemail box can be shared among a few users.
===Custom Personal Announcement===
* [[Howto:Deploy A Custom Personal Announcement For the innovaphone Voicemail|Deploy A Custom Personal Announcement For the innovaphone Voicemail]]
Explains where to copy an externally generated personal announcement file.
===A Simple Recording Solution On-Top of The innovaphone Voicemail===
* [[Howto:A Simple Recording Solution On-Top of The innovaphone Voicemail|A Simple Recording Solution On-Top of The innovaphone Voicemail]]
This article explains how a simple recording solution could be set up on-top of an innovaphone Voicemail.
===Send Email MWI Notification From The innovaphone Voicemail===
*[[Howto:Send Email MWI Notification From The innovaphone Voicemail|Send Email MWI Notification From The innovaphone Voicemail]]
This functionality is available from on SR2 and allows to send MWI notifications by email.

==Quick Reference For innovaphone Voicemail==
* [[Howto:Quick Reference For innovaphone Voicemail|Quick Reference For innovaphone Voicemail]]
The article outlines the menu structure and provides a few operational hints from a user's perspective.

==Known Problems==
The VM makes use of V6’s media negotiation capabilities.
This is why V5 endpoints are not supported.

*[[Support:Voicemail Calls Hanging Around In PBX Call Monitor|Support:Voicemail Calls Hanging Around In PBX Call Monitor]]
*[[Support:Voicemail: Voicebox Not Configurable With "Send Number" set|Support: Voicemail: Voicebox Not Configurable With "Send Number" set]]
* When the voicebox is created upon the first call to the users voicemail, you must not have the ''Send Number'' property configured in the calling user object. Otherwise, the voicebox will be created for the wrong number
* [[Support:Voicemail Fails With "Missing Voicemail License!"|Support:Voicemail Fails With "Missing Voicemail License!"]]
*[[Support:Voicemail Fails With "Authentication Required"|Support:Voicemail Fails With "Authentication Required"]]
*[[Support:Webdav_Access_Slow_From_Windows_7_/_Vista|Support:Webdav Access Slow From Windows 7 /Vista]]

== Related Articles ==

===Voicemail Installation===

* [[Howto:How to setup an V6 IP Phone for innovaphone voicemail usage]]
* [[Howto:Send Email MWI Notification From The innovaphone Voicemail]]
* [[Howto:Quick Reference For innovaphone Voicemail]]
* [[Howto:Forward your Mobile's Mailbox to your innovaphone Voicemail]]

===Voicemail on Compact Flash===

* [[Howto:General information for compact flash cards]]
* [[Howto:Installing the voicemail/music on hold on a compact flash card]]

===Voicemail Customising===

* [[Howto:Deploy A Custom Personal Announcement For the innovaphone Voicemail]]
*[[Howto:Does innovaphone voicemail support multiple announcements?]]
* [[Howto:How To Send Additional MWIs within a PBX]]
*[[Howto:Send Email from the innovaphone Voicemail without saving data on the CF]]
*[[Howto:Localize Voice Mail Messages]]

===Voicemail Scripting===

*[[Howto:Implement a simple caller notification]]
*[[Howto:Getting started with your own PBX voicemail script]]
*[[Howto:Debug_your_own_PBX_voicemail_script]]
*[[Howto:A Simple Recording Solution On-Top of The innovaphone Voicemail]]
*[[Howto:Voicemail Scripting And Projektcode, PIN, Auth Code]]
*[[Howto:Simple ACD with Voicemail XML Script]]
*[[Howto:Control Call Forward with Voicemail XML Script]]

== Download ==
The voicemail product can currently be found on the [http://download.innovaphone.com/ice/6.00/#apps apps section] of the innovaphone download site. This product is suitable for PBX firmware ''versions 6 and up''.

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