Ipo Configuration Service En

IP Office Configuration Service Programmers Guide

Abstract This document details the Application Programming Interface (API) for the IP Office Configuration Service component. It details the operation of the API and the data that is exchanged to effect the supported configuration changes on user and group objects.

15-601473 Issue 1a (28th July 2008)

Programmers Guide Page 2 IP Office Configuration Service 15-601473 Issue 1a (28th July 2008)

2008 Avaya Inc. All Rights Reserved.

Notice While reasonable efforts were made to ensure that the information in this document was complete and accurate at the time of printing, Avaya Inc. can assume no liability for any errors. Changes and corrections to the information in this document may be incorporated in future releases.

Documentation Disclaimer Avaya Inc. is not responsible for any modifications, additions, or deletions to the original published version of this documentation unless such modifications, additions, or deletions were performed by Avaya.

Link Disclaimer Avaya Inc. is not responsible for the contents or reliability of any linked Web sites referenced elsewhere within this Documentation, and Avaya does not necessarily endorse the products, services, or information described or offered within them. We cannot guarantee that these links will work all of the time and we have no control over the availability of the linked pages.

License USE OR INSTALLATION OF THE PRODUCT INDICATES THE END USERS ACCEPTANCE OF THE TERMS SET FORTH HEREIN AND THE GENERAL LICENSE TERMS AVAILABLE ON THE AVAYA WEBSITE AT http://support.avaya.com/LicenseInfo/ (GENERAL LICENSE TERMS). IF YOU DO NOT WISH TO BE BOUND BY THESE TERMS, YOU MUST RETURN THE PRODUCT(S) TO THE POINT OF PURCHASE WITHIN TEN (10) DAYS OF DELIVERY FOR A REFUND OR CREDIT.

Avaya grants End User a license within the scope of the license types described below. The applicable number of licenses and units of capacity for which the license is granted will be one (1), unless a different number of licenses or units of capacity is specified in the Documentation or other materials available to End User. Designated Processor means a single stand-alone computing device. Server means a Designated Processor that hosts a software application to be accessed by multiple users. Software means the computer programs in object code, originally licensed by Avaya and ultimately utilized by End User, whether as stand-alone Products or pre-installed on Hardware. Hardware means the standard hardware Products, originally sold by Avaya and ultimately utilized by End User.

License Type(s): Designated System(s) License (DS). End User may install and use each copy of the Software on only one Designated Processor, unless a different number of Designated Processors is indicated in the Documentation or other materials available to End User. Avaya may require the Designated Processor(s) to be identified by type, serial number, feature key, location or other specific designation, or to be provided by End User to Avaya through electronic means established by Avaya specifically for this purpose.

Copyright Except where expressly stated otherwise, the Product is protected by copyright and other laws respecting proprietary rights. Unauthorized reproduction, transfer, and or use can be a criminal, as well as a civil, offense under the applicable law.

Third-Party Components Certain software programs or portions thereof included in the Product may contain software distributed under third party agreements (Third Party Components), which may contain terms that expand or limit rights to use certain portions of the Product (Third Party Terms). Information identifying Third Party Components and the Third Party Terms that apply to them is available on Avayas web site at: http://support.avaya.com/ThirdPartyLicense/

Avaya Fraud Intervention If you suspect that you are being victimized by toll fraud and you need technical assistance or support, call Technical Service Center Toll Fraud Intervention Hotline at +1-800-643-2353 for the United States and Canada. Suspected security vulnerabilities with Avaya Products should be reported to Avaya by sending mail to: [email protected].

For additional support telephone numbers, see the Avaya Support web site (http://www.avaya.com/support).

Trademarks Avaya and the Avaya logo are registered trademarks of Avaya Inc. in the United States of America and other jurisdictions. Unless otherwise provided in this document, marks identified by , and SM are registered marks, trademarks and service marks, respectively, of Avaya Inc. All other trademarks are the property of their respective owners.

Documentation information For the most current versions of documentation, go to the Avaya Support web site (http://www.avaya.com/support) or the IP Office Knowledge Base (http://marketingtools.avaya.com/knowledgebase/).

Avaya Support Avaya provides indirect and direct services for customer support, report problems or to ask questions about your product. These services are subject to your support agreement. Contact your local reseller / distributor for indirect support. Contact Avaya Global Services (AGS) for direct support. For additional information on support, see the Avaya Web site: http://www.avaya.com/support.

http://support.avaya.com/LicenseInfo/http://support.avaya.com/ThirdPartyLicense/mailto:[email protected]://www.avaya.com/support


Contents 1 IP Office Configuration Service ................................................................................................................. 1

1.1 Key Terms Used in this Document...................................................................................................... 1 1.2 Introduction..................................................................................................................................... 2 1.3 Runtime Requirements...................................................................................................................... 3

2 Architectural Overview............................................................................................................................. 4 2.1 Configuration Consistency ................................................................................................................. 6

3 IP Office Configuration Service Methods.................................................................................................... 7 3.1 Primary Service Methods ................................................................................................................... 8

3.1.1 GetUnitConfiguration Method ................................................................................................... 8 3.1.2 SetUnitConfiguration Method.................................................................................................... 8

4 XML Format.......................................................................................................................................... 10 4.1 Overview ....................................................................................................................................... 10 4.2 Document Root .............................................................................................................................. 10 4.3 User .............................................................................................................................................. 11

4.3.1 DSS Keys ................................................................................................................................ 15 4.4 Groups .......................................................................................................................................... 18

4.4.1 Group Membership................................................................................................................... 21 5 Hosting and Secure Configuration Guides ................................................................................................ 22

5.1 Configuring Secure Transport on IP Office ........................................................................................ 22 5.2 Hosting under IIS ........................................................................................................................... 24

1 IP Office Configuration Service

1.1 Key Terms Used in this Document General industry terms and their acronyms are introduced inline, as in TCP (Transmission Control Protocol) when first used in a section, if the term is either sufficiently new or specific to this architecture then it will be documented in this section and an explanation provided.

BINDING WCF (see below) binding directive, used to configure the protocol utilized, basicHttpBinding and wsHttpBinding for example. Binding also can be configured to affect policy and security.

GUID Global Unique Identifier. A 128bit number written as a sequence of hexadecimal digits.

OPP Operation Code, an attribute supplied that identifies how an element and its data should be processed. The defined operations are Update, Add and Delete.

UCC Upper Camel Case. Naming convention, where words are compounded together and the first letter of each word is capitalized.

WCF Windows Communications Foundation, a unified communications programming model implemented as part of the .Net 3.0 technology stack.

WinFx Microsofts Framework for delivering key Communications/Presentation API on Windows XP (SP2)/Vista client operating systems and Windows 2003 and Longhorn Server.

When there are important concepts to explain a note section will be used to breakout the detail and bring them to your attention.

Note These notes provide useful information, about the current subject


1.2 Introduction The API enables integrators and ISVs to incorporate robust configuration changes into their solution via a web service interface, expressing configuration changes via an XML document. It enables changes to be made to the following IP Office entities:

User Group

Subsets of the available fields are supported for each entity, which fulfils the majority of use-cases targeted by this release. These supported fields are documented in the XML document section. Two methods are exposed by the service interface; these are designed to support hosting under IIS or can be self hosted. The service interface utilizes the Windows Communications Foundation (WCF); this technology supports a number of hosting scenarios, such as self hosted. The IIS hosted approach will be the only method discussed in this document. These methods are used to get the configuration from the IP Office (GetUnitConfiguration) and set the configuration respectively (SetUnitConfiguration). Both methods work by supplying or consuming an XML document, the XML format is consistent across a get/set for the supported User/Group entity fields. When making configuration changes, an Opp (Operation Code) attribute is used to indicate the desired operation against an entity. The following Opp are supported:

Add Update Delete

The XML document need only contain the change fields for the new or updated data, a summary document is returned from the set method to indicate if the configuration changes were successfully applied, or if the changes resulted in a validation message. The following validation levels are used:

Informational Warning Error

The GetUnitConfiguration method call returns the supported User and Group entities and their supported fields, along with additional supporting information such as the handset for the User record. Additional supplemental data is also supplied; this can be used to support your validation logic if required. The data supplied includes:

Unit Name and software version number Extensions, Extn Number, Port, Phone Type User Rights, template name Existing Validation, messages

Note It is imperative that you have a good understanding of the configuration and management of IP Office and that you are comfortable using the Manager application.



1.3 Runtime Requirements

Component Requirement

Software

Operating System Windows Server 2003 SP1 (Standard Edition, Enterprise Edition, or Datacenter Edition), depending on load/usage a client OS Windows Vista or Windows XP may be adequate (subject to your own load and capacity evaluation).

Web Server for hosting the web service IIS 6.0

.NET Framework Version 3.0

ASP.NET 2.0 Visual Studio 2005 C++ SPI C/C++ runtime

Runtimes

You install IIS 6.0 by using the Windows Control Panel. For details, see the Windows Server documentation. To download Service Pack 1 for Windows Server 2003, go to http://www.microsoft.com/windowsserver2003/downloads/servicepacks/sp1/default.mspx. To download the .NET Framework, go to http://www.microsoft.com/downloads/details.aspx?familyid=10CC340B-F857-4A14-83F5-25634C3BF043&displaylang=en To download the C++ runtime (Visual Studio 2005 SP1), go to http://www.microsoft.com/downloads/details.aspx?FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647&DisplayLang=en

http://www.microsoft.com/windowsserver2003/downloads/servicepacks/sp1/default.mspxhttp://www.microsoft.com/downloads/details.aspx?familyid=10CC340B-F857-4A14-83F5-25634C3BF043&displaylang=enhttp://www.microsoft.com/downloads/details.aspx?familyid=10CC340B-F857-4A14-83F5-25634C3BF043&displaylang=enhttp://www.microsoft.com/downloads/details.aspx?FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647&DisplayLang=enhttp://www.microsoft.com/downloads/details.aspx?FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647&DisplayLang=en

2 Architectural Overview The solution targets the Windows 2003 Server platform and utilizes the Microsoft .Net framework 3.0 to provide a robust and scalable service implementation. The service interface is hosted using the Windows Communications Framework (WCF), to enable flexible hosting of the service as a standalone executable or via IIS. The web service enables non windows platforms to consume its services if required, based on a standard http based binding.

Communication between the Avaya IP Office Configuration Service and the customers IP Office is over TCP using a secure connection. Transport Layer Security (TLS) is utilized to establish a session between the configuration service and the IP Office for the duration of a transfer to/from the service and the IP Office. The port number of the IP Office services can be configured for individual systems using the security manager (introduced in the IP Office Manager Release 4.1) when the system is commissioned. The default ports are as follows: IP Office Service Unsecured Secured Comment Configuration 50804 50805 This is the only interface

utilized by the Avaya IP Office configuration component.

Program 50806 50807 System Status Interface 50808 50809 Directory Lists 50810 50811 Security Administration 50812 50813 Whois_2 50802 Utilized by Manager, replaces

UDP based whois.

These ports are based on a base port defined via the security manager, so adjustments to the base port move the ports en bloc; please review the necessary IP Office 4.1 details for these and other changes/options regarding TCP/UDP services. IP Office can be configured to meet different security expectations; the security configuration is separate from the core unit configuration. With the exception of the Whois_2 port, the IP Office enables the security to be configured to support insecure/secure and secure or insecure access to these services, dependant on the level of authentication required. Legacy UDP based service can also be locked down. A secure port only will be used to access the IP Office, the level must be set to low (the inbuilt certificate that IP Office generates will be utilized, when a secure service is configured). The certificate is used to enable key exchange only and is not verified. The service will trust the inbuilt certificate presented from the IP Office to enable the secure session to be established.

Note The security level must be set to low, to enable use of the inbuilt certificate.


The services utilizes the secure connection and authentication credentials supplied to retrieve the binary configuration file from the IP Office, the file is unpacked into an object representation before converting the supported subset of information into XML. The same steps are taken when applying configuration changes, retrieve the file from the IP Office at the latest possible moment, before applying the changes embodied in the XML configuration, validation takes place during processing if no errors are detected representation is repacked and transferred back to the IP Office.

Service Interface

Avaya IP Office Configuration Service Contract

Service Adaptor

Configuration Service

Transport

Application

Abstraction EntitiesConfiguration Validation

Configuration XML Processor (CRUD)

Secure Tranport

IP Office

Connectivity Validation

TCP (TLS)

TCP

Request Configuration Representation Document Action Configuration Request

Document

Figure 1 - Logical Architecture


2.1 Configuration Consistency

The following strategies are used to handle data consistency. Data changes are always applied to the most recent configuration. This involves fetching the configuration binary from the unit, prior to applying the updates and then returning the configuration binary promptly. These steps are sequential within a service invocation. The configuration XML file contains the entities and field changes only, these changes are applied to the configuration. Scoping the changes to only the fields that have been affected reduces the amount of data required to be processed and ensures only the data that needs to be touched is affected. This approach is embodied in the format of the XML changes document. The entity level flag on the changed item (user, group, etc) will be set to indicate which entities have been changed; this enables the IP Office to process the new configuration file specifically merging the entities that have been marked. This isolates the impact of locally changed values at an entity level, as a binary diff is used to identify changes to records. Being explicit ensures that entities that have not been flagged explicitly are not considered for merging. The approach reduces the impact on the total system configuration and focus the changes to just the affected entities and within these entities only the relevant fields. The overall configuration strategy is no less vulnerable than having two local manager instances, where last change wins. If the entity changes are not overlapping, then both updates will be successful. These behaviors and operations will be consistent with the standalone manager operation. It is recommended that consumers of the service implement a strategy to avoid concurrent overlapping configuration writes. If your application supports multiple concurrent clients, then your solution should aggregate these requests and serialize the requests to the configuration service.

Note If your integration requires multiple concurrent requests, provide a service faade to queue the requests before calling the service. IP Office makes live the configuration changes approximately 2 seconds after processing the received configuration.


3 IP Office Configuration Service Methods The service exposes the following two primary methods:

GetUnitConfiguration SetUnitConfiguration

The service interface utilizes a string type to return the XML representation of the configuration items and likewise the SetUnitConfiguration method will accept an XML document defined as a string type to transfer the configuration updates. This arrangement will allow the same interface to be utilized as the solution evolves over time; the content of the XML infers what operations are required and the structure is kept simple to allow future extensibility.

Note The service interface is hosted under IIS, via a svc file. The URL of the service endpoint is determined by your configuration. You will typically need to access the Web Services Description Language (WSDL) of the service to build a proxy in your development environment.

The service exposes a utility method (ConnectAndGetUnitDetails) that can be used to check if the IP Office is reachable, the method also returns some basic unit information including:

UnitName IPAddress Unit Type Software Version Unit MAC Address

The service utilizes the internal implementation to assert if the unit is reachable before attempting to retrieve configuration data from the IP Office.


3.1 Primary Service Methods

The two service methods enable you to retrieve (GetUnitConfiguraiton) configuration data as XML and make changes to configuration (SetUnitConfiguration) via a XML configuration document. These methods are stateless, a new session is created per request, and this enables multiple services to be deployed across PCs utilising a load balancer if high scalability is required.

3.1.1 GetUnitConfiguration Method

The following parameters are required:

Unit IP Address (string) Unit Configuration Service Port number (Int32) Service Account Name (string) Service Account Password (string)

The return value is an XML document that represents the configuration elements on success or a fault message indicating the nature of the error.

3.1.2 SetUnitConfiguration Method

The following parameters are required:

Unit IP Address (string) Unit Configuration Service Port number (Int32) Service Account Name (string) Service Account Password (string) Configuration XML directives (XML document) Batch Transactional (bool)

The return value is an XML document with summary request data or a fault contract that represents the nature of the failure ConnectivityFault containing a fault reason code and an error description. The ConnectivityFault is returned to indicate an unrecoverable condition, such as the unit being unreachable, failing authentication or invalid XML being supplied. The summary return data provides feedback on the number of issues related to the changes processed, if the information is informational or a warning then the changes would have been applied, indicated by the ConfigTransferred element containing a true value. If Errors are detected, these will be indicated in the Errors element as a count, details of the validation errors are returned, referencing the original GUID used and a detailed description of the failure.

Note When errors are caused by incoming change requests a decision is made based on the BatchTransactional flag, either to continue disregarding the failed change request and continue processing other potential valid requests or fail all changes and not commit back the configuration. In either case, if errors are detected in the completed configuration update, they are never committed back to the IP Office. This enables you to accept failures and get feedback, while only applying valid changes that pass validation to succeed.

Setting BatchTransactional to false will enable partial changes to succeed, while a true setting will not allow partial failures.


Example Summary Return Data on a successful method call:

0 0 0 0 False True

Note When adding a new user or group, a GUID is supplied as a unique reference, the GUID in this case is only valid for the request, IP Office will allocate a new GUID for the record and utilize its own MAC address for the relevant portion of the GUID. Any errors or validation issues will utilize the supplied GUID to ensure a consistent reference, it should not be persisted.


4 XML Format

This section describes the format of the XML document used to effect configuration changes. The document is based on the format retrieved as a result of a GetUnitConfiguration, with the addition of an Opp code to signify the intent of the change at a User/Group level. User records have additional DSSKey sub elements that can be individually set. The same Opp code attribute can be expressed for each individual element representing a key.

4.1 Overview

The document format is composed of a root element and sub elements that are categories of configuration data expressed as plurals for example Users, these in turn contain the type of element using the singular, for example User. The element that represents the record of an entity is composed of two attributes; the first is the GUID of the object (its unique key) and the operation to be performed if the document is a configuration change document. The child elements use the manager field names (English) to identify the field of a record and the value is contained as the inner text of the element.

The XML data will be UTF-8 encoded. The elements and attributes use Upper Camel Case (UCC), to capitalize the first character of each word and compound the name.

Note The XML naming is mainly aligned with the Manager application fields. Manager is a great learning tool for round tripping between the service to observe how your changes are applied/rendered in XML.

4.2 Document Root

The document root element is AvayaIPOConfiguration. The elements that support configuration changes are User and Group; each is contained in a parent element named Users and Groups respectively. The table below shows how the overall XML document is structured.

Document Root Parent Elements Entity Element Comments Root element Users container User record Groups container Group record

Table 1


4.3 User

User elements are contained by the Users container as shown in table 1, they represent the user record and inbuilt users such as NoUser, a template used for new user records.

Note User records generally should be updated. A system automatically creates a user record for each extension and associates the two. The ability exists to delete and add user records, if required.

User Mandatory/ Optional

Attributes Comments

M Guid The GUID unique key of the user record

M Opp Opp code for change Add, Update, Delete

Example:

Note Name and FullName fields do not support the following punctuation characters ,(),#,?,/,-,+,=,,$,*,~,@,%, < and comma.

User Element Mandatory/ Optional

Value Comments

Name O/M The record name of the user, traditionally Extn206. Mandatory on an Add operation.

A textual key; must not contain spaces or reserved characters.

Example: Extn206

User Element Mandatory/

Optional Value Comments

FullName O Full user name, displayed on phone.

Full name of the user displayed in the directory.

Example: Jack Sparrow




Value Comments

Password O User records password Phone Manager, Softconsole, Dialin and TAPI password.

Example: 150697



Extn O Extension Number A valid extension number not already in use. A list of extensions is provided in a GetUnitConfiguration, each use record also contains this element.

Example: 4769



VoiceMailOn O True/false Turns VoiceMail on or off for the user record.

Example: true



VoiceMailCode O 15 digits maximum Voicemail access password.

Example: 4769



Value Comments

CanIntrude O true/false Sets the intrude ability of a user record.

Example: true



CannotBeIntruded O true/false Sets the can be intruded ability of a user record.

Example: false


Value Comments

XDirectory O true/false Sets the user record directory visibility.

Example: false


Value Comments

UserRights O User Rights template name. Provide an empty element to remove any associated template.

Inherits settings of named User Rights template. A list of templates is provided via the GetUnitConfiguration method. They are contained in a element, for each template there is a element with a Name attribute that contains the name of the template.

Example: CustomUser

Note The user record also supplies some associated data, PhoneType and PhoneTypeIndex, these values reflect the type of phone device connected on the port associated with the extension. This could be used to present some form of UI representing the device, the PhoneType text is descriptive.

Applications such as PhoneManager, utilize these additional buttons, even though the device is unable to display them.



Value Comments

PhoneType N/A Phone Type The type of phone associated with the users extension.

PhoneTypeIndex N/A PhoneType enumeration Enumeration of the phone type, supplied only.

4.3.1 DSS Keys

DSS keys can be programmed using a subset of the available features. Each key is individually identified by a key number and requires an Opp code attribute to indicate the operation to be performed such as Add, Update or Delete.

Note There are a number of rules that must be met regarding positions of certain buttons. Any Call Appearance button must occupy the first button position and be contiguous if additional Call Appearance buttons are programmed.

Coverage and Bridged appearances must have valid targets specified and there must be at least one Call Appearance button programmed occupying the first button position.

When deleting buttons any dependant button should be deleted first, for example a Bridged appearance which has a dependency on a Call Appearance.

Coverage and Bridged appearances must not be duplicated.

DSS Keys are scoped within the User element, and contained by a element. Each key definition is described by a element and two attributes are used to convey the key number and the operation to be performed. Table 2 shows how the DSSKeys container scopes the DSSKey.

User Record Parent Elements Entity Element Comments Container for individual keys Key entry, attributes Key number to be

programmed and operation to perform Display data Function Associated data, dependant on function

Table 2

Note Please refer to the Manager application help file for complete details on the features supported.



Function Action Object

Mandatory/ Optional Data Item

Data Comments

AbbreviatedDial M Full/Partial number to dial

Use the label to display a caption

AbbreviatedDialProgram N/A Initiate user abbreviated programming from the handset.

AccountCode O Set the account code. AutoDial M BridgedAppearance M Busy N/A CallForward O Forward number Acts as a toggle if the feature is activated,

confirms/prompts for forward number if not set. If the number was supplied, then the number cannot be changed, the button toggles the Call Forward feature.

CallIntrude M Numeric extn number CallListen M Numeric extn number CallPark O Blank for default or specific park slot number CallPickup N/A CallAppearance M a=, b=, c= Must occupy the first button position, must be

contiguous if more the one appearance is required.

CoverageAppearance M DialPaging O Directory N/A DoNotDisturbOn N/A Button Toggles DND ExtnLogin N/A ExtnLogout N/A FollowMeTo N/A Prompts for location FollowMeHere FollowMeHereCancel O Extn Number Must be cancelled from the extension that was

originally set as the follow me target. ForwardHuntGroupCallsOn N/A Acts as a toggle ForwardHuntGroupCallsOff N/A ForwardUnconditionalOn N/A Acts as a toggle, uses the configured forward

number. HuntGroupNightService Hunt group extn number Acts as a toggle SetHuntGroupOutOfService Hunt group extn number HuntGroupEnable O Hunt group extn or

blank for all

SetAbsentText M 1/0 for on/off, message number, custom text

TimeOfDay N/A UserBLF M Extn Number VoicemailOn N/A VoicemailOff N/A VoicemailCollect M

Table 3

4.3.1.1 DSS Key Examples

The following examples show how the DDS keys are programmed.

Note DSS Keys are scoped by the owning user entity, each key needs to specify the Opp code to effect the desired change, and the owning user record required the Opp code to indicate that there are changes.

Keys are identified by the Key attribute, which starts at 1

The examples utilize the supported features documented in table 3, a full example is first shown to display the full scoping of the containing entities, including the root:

Example:

CallAppearance a= 0

Note DSS Keys are processed sequentially, so order your updates/deletes/adds to ensure you dont break any rules regarding ordering or prior dependencies. If your needs are more complex it may be more effective to delete and recreate the key structure. Internally keys occupy an array slot ordered by key number, so add and update are the some underlying operation.



4.4 Groups

The API is designed to support local groups only, not distributed hunt groups. The Groups container scopes the Group record as indicated in table 1.

Group Mandatory/ Optional

Attributes Comments

M Guid The GUID unique key of the group record

M Opp Opp code for change Add, Update, Delete

Example:

Group Element Mandatory/


Name O/M Unique name. Mandatory on an Add operation.

Must not contain any reserved characters. Max 35 characters.

Example: Emil



Extn O/M The number of the group The number must be available and not allocated to a user or existing group; the get configuration method provides details of existing groups and extension numbers. The extn number is mandatory on an add operation. Range 2-9 digits.

Example: 700


Group Element Mandatory/ Optional

Value Comments

NoAnswerTime O Number of seconds 1-99999 secs, default 15

Example: 20



VoicemailAnswerTime O Number of seconds 1-99999 secs, default 45

Example: 45



GroupRingMode O Rotary Collective Sequential LongestWaiting

Default Sequential

Example: Rotary



VoicemailOn O true or false Defaults to On; does not affect other mailbox usage: recording, messages forwarded from other mailboxes.

Example: false


Group Element Mandatory/ Optional

Value Comments

VoicemailCode O passcode Range 0-15 digits, default is blank.

Example: 12345


4.4.1 Group Membership

Group Membership is expressed as a set of Member elements scoped by a Members element container, the container is scoped by the Group entity containing element. You manipulate these in a similar manner to DSS Key entries for a user, in that each member has an Extn attribute to indicate the members extension number and an Opp code to indicate the desired operation Add, Update, Delete. The Enabled status is set via an element with a true/false value.

Group Record Parent Elements Entity Element Comments The Group level must

contain an Opp code attribute of update.

The member extension is

expressed as an attribute. true

Enabled status

Full Example Creating a new group and setting the members: Mark 400 Sequential true true true true

5 Hosting and Secure Configuration Guides The following sections provide guidance on how to secure the IP Office transport via the new secure service configuration capabilities in the 4.1 and above release of IP Office. Guidance is also provide on how to host the service under IIS. While we focus on this method, it is worth mentioning that there are a number of other hosting models available, that may be more suitable to your particular needs, please see the WCF documentation available on-line at http://msdn.microsoft.com.

5.1 Configuring Secure Transport on IP Office IP Office 4.1 and higher stores a separate security configuration, which is accessible via the security settings editor in manager. You access the security settings via File->Advanced->Security Settings menu on the Manager application, you select the unit and establish a logon using a security account, the default account on a new system is security and the password is securitypwd. This is a quick guide to getting the necessary secure configuration transport enabled. When first configuring a system, its prudent to ensure that the configuration service has both secure and unsecured access, to support existing access via Manager over UDP, until you are confident about securing the system. Deployment of a secured system is dependent on customer needs, but the service API only supports secure access. Configure the Services, select the Service node from the tree and expand the Group pane to display, select the Configuration service. Initially configure it to support both Unsecure + Secure see the diagram below.

Note Creating certificates is system intensive; it can take few minutes to create a new certificate, to please be patient. Selecting any secure option will generate an internal certificate. Save the options.

Open the security settings after a few minutes the exact time is dependent on your IP Office hardware (IP 500 creates a certificate in about 30 seconds, while a Small Office can take 15 minutes)


http://msdn.microsoft.com/

If you select the System node in the tree you will see that an internal certificate has been created based on the string IP Office + MAC Address. See the following diagram for reference.

Note You can configure Manager to utilize the secure connection, via the File->Preferences Security Tab.

Check that you can access the IP Office using a secure connection with Manager, to confirm your configuration is valid. A small shield is displayed in the bottom right status bar of Manager to indicate it is using a secure connection.



5.2 Hosting under IIS

To host the service under IIS, you need to create a virtual directory to host the web application, using the Internet Information Services (IIS) Manager. At the physical location used to host the web application, a bin sub directory is required to host the service binaries. In the root of the application a service.svc file is required to expose the service, it needs to contain the service details as follows: The binaries should be copied to a bin directory. The deployment model is the same as a .Net web application. To complete the installation a web.config file is required in the web application root to configure the service. If you have an existing configuration, merge in the service elements shown below for reference.

There are many choices to consider based on your deployment scenario, WCF supports a number of profiles to meet interoperability and various levels of security, please refer to the following on-line detailed article: WCF - Configuring Services http://msdn2.microsoft.com/en-us/library/ms733830.aspx

Note The two key bindings are basicHttpBinding used to enable interoperability, there is no security by default, and transport level security can be established using a secured transport https. The more advanced ws* protocols are enabled by configuring the binding to use wsHttpBinding, this enables access to the more secure standards and security is enabled by default. The windows account is utilized by default, there are other authentication alternatives including custom ASP.Net and certificate authentication.

These can all be configured via the configuration file.

Access to the WSDL is only required to develop your proxy, you should turn off access to the service definition when your service is deployed in a live environment.


http://msdn2.microsoft.com/en-us/library/ms733830.aspx


Performance figures and data quoted in this document are typical, and must be specifically confirmed in writing by Avaya before they become applicable to any particular order or contract.

The company reserves the right to make alterations or amendments to the detailed specifications at its discretion. The publication of information in this document does not imply

freedom from patent or other protective rights of Avaya or others. Intellectual property related to this product (including trademarks) and registered to Lucent

Technologies have been transferred or licensed to Avaya. All trademarks identified by the or are registered trademarks or trademarks, respectively,

of Avaya Inc. All other trademarks are the property of their respective owners. This document contains proprietary information of Avaya and is not to be disclosed or used

except in accordance with applicable agreements. Any comments or suggestions regarding this document should be sent to

"[email protected]". 2008 Avaya Inc. All rights reserved.

Avaya Unit 1, Sterling Court

15 - 21 Mundells Welwyn Garden City

Hertfordshire AL7 1LZ

United Kingdom Tel: +44 (0) 1707 392200 Fax: +44 (0) 1707 376933

Web: http://www.avaya.com/ipoffice/knowledgebase

1 IP Office Configuration Service1.1 Key Terms Used in this Document1.2 Introduction1.3 Runtime Requirements

2 Architectural Overview2.1 Configuration Consistency

3 IP Office Configuration Service Methods3.1 Primary Service Methods3.1.1 GetUnitConfiguration Method 3.1.2 SetUnitConfiguration Method

4 XML Format4.1 Overview4.2 Document Root4.3 User4.3.1 DSS Keys4.3.1.1 DSS Key Examples

4.4 Groups4.4.1 Group Membership

5 Hosting and Secure Configuration Guides5.1 Configuring Secure Transport on IP Office5.2 Hosting under IIS

Documents

Ipo Configuration Service En