Reference10:SOAP API: Difference between revisions

From innovaphone wiki
Jump to navigation Jump to search
m (Redirecting to Reference10:Concept SOAP API)
 
Line 1: Line 1:
innovaphone®’s PBX web services (a.k.a ''SOAP API'') are enhanced from time to time. The current WSDL file defining the interface is [http://www.innovaphone.com/wsdl/pbx10_00.wsdl ''pbx10_00.wsdl''].
#REDIRECT [[Reference10:Concept SOAP API]]
 
Applications based on this wsdl will work with V10 PBX firmware only.
Applications written to the previous wsdl will still work.
 
==Overview==
 
For an overview of the basic architecture, see the [[Reference:SOAP_API_%28pbx501.wsdl%29#Overview|corresponding chapter in the pbx501.wsdl related article]].
 
[[Category:Concept|{{PAGENAME}}]]
 
== Definition of PBX object (WSDL) ==
Within the SOAP framework there is a mechanism to formally decribe the definition of remote objects. This is done by so called WSDL (Web Service Description Language) files. This [[http://www.innovaphone.com/wsdl/pbx800.wsdl wsdl file]] defines the PBX web services  described in this document.
 
<small>There is also an [[http://www.innovaphone.com/wsdl/pbx.wsdl old version of the wsdl]] available which has less interface functions.  This interface can still be accessed by legacy applications and is activated on the PBX by calling the '''Initialize''' Function with fewer arguments ('''Integer Initialize(string user, string appl, out key)''').  It should not be used for new develoments though.</small>
 
=== SOAP URL ===
The SOAP service URI is '''/PBX0/user.soap''' for the standard PBX and '''/PBX-''id''/user.soap''' for a dynamic PBX (where ''id'' corresponds to the ''Id'' field in the [[Reference8:Administration/PBX/Dyn-PBXs]] configuration dialog).  SOAP is accessible via plain HTTP or HTTPS, so valid URLs might be <code>http://172.16.0.1/PBX0/user.soap</code> or <code>https://172.16.0.1/PBX0-mydynpbxid/user.soap</code>.
 
==PBX Objects and Methods==
 
This section contains a language agnostic description of the PBX API’s object model.  Despite of the fact that we are discussing an object model, the PBX API is in fact not an object oriented API.  This is because SOAP itself is not really object oriented.  In particular, there is no object creation, activation or lifetime concept.  This is left up to the service designer.  SOAP is more a message exchange mechanism than an object method invocation mechanism.  This is reflected in the API structure.
 
Specifically, objects are represented through handles, which are integers.  Objects are created and destroyed using dedicated methods and it’s the users responsibility to manage the lifetime of all objects.
 
The syntax shown here actually is no valid syntax in any existing language.  Please refer to the various sample codes for working syntax.
 
===Session===
 
All PBX API methods are executed in the context of a session.  A session is created using the '''initialize''' method and is identified by a handle.  This handle must be provided to all subsequent method calls.
 
A session is owned by the PBX API user, i.e. there is no way to have access to a session of another application.  Each session has a scope, which defines the view of the PBX the session user has.  The scope determines the set of PBX registrations seen by the session.
 
Scopes are defined and configured in the PBX and are bound to particular PBX users. Thus, a session has a user attribute, which defines the scope.  It includes all users which are members of groups '''user''' is active member of.  If '''user''' is not an active member of any group, the scope is the user itself.
 
 
====Initialize(string user, string appl, bool $v, bool $v501, bool v700, bool v800, out int key)====
 
To access the current web services implementation, '''v''', '''v501''', '''v700''' and '''v800''' must be present and set to '''true'''.
These parameters actually convey the wsdl version used by the client.  Different versions of the interface use different parameter sets for the Initialize call.  Applications should always use the wsdl version current at the time of writing the application.
 
The method creates a session.  The session will have the user '''user'''’s scope.  The session handle is returned and is 0 for failure and positive for a valid session handle.  '''appl''' specifies the name of the calling application and is used for administrative purposes.  The output parameter '''key''' is a random number associated to the session.  It may be used in subsequent '''Echo''' operations.
 
When a session is created, '''UserInfo''' events for all PBX registrations in the scope can be received by the '''Poll''' function.  Initially, one '''UserInfo''' per registration within the session’s scope is received (the list is terminated by a '''UserInfo''' with empty '''cn''' and may require multiple '''Poll''' calls to retrieve).  Subsequently, '''UserInfo''' events are received when a registrations state changes.
 
The underlying transport session (HTTP) must authenticate itself  either as '''user'''  (using the users long name and PBX password) or as the admin user (using the gateway administrator account name and password) to perform an '''Initialize''' and any session related function.  Note that if you use a PBX user account, the user needs to have at least ''Group/Call Forwards'' rights.
 
Note that the method to force the SOAP system you are using to authenticate to the PBX is entirely up to the system itself.  Some systems even do not support authentication at all.  If your SOAP implementation does not support digest authentication, make sure the gateway accepts basic authentication by setting the “''allow HTTP basic authentication''” in the “''General settings''”.
 
Note that although many HTTP connections may be used in a single session, at least one HTTP connection must remain open during the lifetime of the session.  When the last connection disappears, the logical session is terminated after a short timeout. Some SOAP libraries may per default always close the HTTP connection and reconnect on subsequent SOAP calls, which will not work. The SOAP library should either be configured to keep at least one HTTP connection alive or, if this is not an option, the application should take care to always have a an active request pending (such as '''Poll''').
 
====Echo(integer session, integer key)====
 
Verifies a session.  You need to supply the ''session'' identifier and ''key'' returned by a previous call to '''Initialize'''.  Returns nonzero if successful.
 
====End(integer session)====
 
Terminates the session referenced by ''session''.  No further events will be received.
 
====Integer Version(out string gkId, out string location, out string firmware, out string serial)====
 
Returns the version number of the WSDL file the PBX supports.  The first released WSDL file had version number 500.  The version described by this document has version number 501. Also delivers information about the connected PBX (in ''gkId'', ''location'', ''firmware'' and ''serial'').
 
====AnyInfo Poll(integer session)====
 
Returns pending events for the session referenced by ''session''.  ''AnyInfo'' is a struct with four arrays as members: ''user'', ''call'', ''reg'' and ''info''. ''user'' is an array of type ''UserInfo'' and call is an array of type CallInfo.  The other two arrays ''reg'' and ''info'' are currently not used.
 
After a successful '''Initialize()'' there will be a ''UserInfo'' event for each defined user in the system.  This allows the application to synchronize on the state of all visible users.  The list will be terminated by an ''UserInfo'' event for a user with an empty ''cn'' which normally cannot happen since a user entry must have a cn.
 
===User===
 
A user represents a configured object within the PBX (a “PBX user”). The PBX API provides the '''UserInitialize''' method to obtain a handle to the user.
 
====UserInfo====
The user’s properties are stored in a ''UserInfo'' structure, which has the following elements:
 
*'''boolean active'''
 
true if the user exists.  The only case where active can be false is when a user is deleted. A single UserInfo event will be posted with active set to false then.
 
*'''integer state'''
 
1 if the user is registered, 0 otherwise.
 
*'''integer channel'''
 
number of current calls.
 
*'''integer  alert'''
 
number of alerting calls
 
*'''string type'''
 
the type of the users device.  Currently defined are “'''ep'''” (it is an endpoint), “'''gw'''” (it is a gateway, for example a trunk line), “'''waiting'''” (a call queue) or “'''broadcast'''” (a group).  Others may be defined over time.
 
*'''string guid'''
 
the users GUID.  This is a globally unique identifier for the user.
 
*'''string cn'''
 
the common name of the user. This is what the PBX’s LDAP server recognizes as the CN of this user.  The user’s name in the PBX configuration applet.
 
*'''string e164'''
 
the extension number the user is registered with.
 
*'''string h323'''
 
the alias the user is registered with.
 
*'''string dn'''
 
the users display name.
 
*'''string domain'''
 
the PBX domain if the Gatekeeper ID is used as domain
 
*'''boolean h323email'''
 
If true, the h323 name shall be used as primary email address when sending emails to this user.
 
*'''string email[]'''
 
email addresses of the user. If 'h323email' is not set, the first address in this list shall be used as primary email address when sending emails to this user.
 
*'''Group groups'''
 
An array of '''Group''' records (see below).
 
*'''Presence presence'''
 
An array of '''Presence''' records (see below).
 
*'''boolean cfg'''
 
If set to true indicates that the config of the user has changed
 
*'''string object'''
 
The type of the user object
 
*'''string loc'''
 
If the object described is not local to the PBX the '''UserInfo''' is sent from, the name of the location the object is homed in is given in this element.  See '''LocationUrl''' to find out how to proceed further.
 
*'''string node'''
 
The node of the object.
 
*'''string nodenum'''
 
The object nodes node number (prefix).
 
*'''Info'''
An '''Info''' record describing various aspects of the user.  The type of the information described in an individual '''Info''' record is determined by the value of its ''type'' member.  Currently defined values for ''type'' are:
 
**'''loc (v501)'''
 
If the object described is not local to the PBX the '''UserInfo''' is sent from, the name of the location of the object is homed in is given in this element.  See '''LocationUrl''' to find out how to proceed further.
 
*'''groups'''
 
The users group memberships are stored in a '''Group''' record which has the following elements:
 
**'''string group'''
 
the name of the group the user is a member of
 
**'''bool active'''
 
true if the user is an active member of the group
 
*'''presence'''
 
The users presence status is stored in a '''Presence''' record which has the following elements:
 
**'''string status'''
 
either '''open''' or '''closed'''
 
**'''string activity'''
 
The users current activity (optional)
 
**'''string note'''
 
The user provided additional note (optional)
 
====integer UserInitialize(integer session, string user, bool xfer, bool disc, string hw)====
 
Returns a handle to the named ''user'' (0 on failure). String <code>user</code> must be a Long Name(cn). Phone number(e164) is not supported. Use FindUser instead, to retrieve cn to specified e164 number.
 
Once a user handle is obtained with '''UserInitialize''', '''CallInfo''' events will be posted and retrieved via '''Poll''' for all calls related to the user.  If '''xfer''' is set to '''true''', '''CallInfo''' events will also be posted for calls which are transferred away from '''user'''.  Otherwise, such events will be posted only for the user handle which the call has been transferred to. Thus, without setting follow to true, an application will generally not be able to track calls after a transfer unless it has called '''UserInitialize''' for any PBX object a call may be transferred to and matches the new call on the transferred-to user via the '''conf''' information in the '''Info''' record of the new call (which will be identical to the '''conf''' information for the transferred call).
 
When '''xfer''' is set to '''true''', transferred calls will show up in the '''CallInfo''' records with a '''No''' element of type '''xfer''' that indicates the number the call has been transferred to.
 
When '''disc''' is set to '''true''', calls to phones of the monitored user are cleared only after the user hangs up the phone. This way it can be avoided that the SOAP application assumes the phone is free but is still off-hook. This only works with innovaphone H.323 endpoints since the Disconnect message used to do this is not defined in the SIP standard.
 
When a '''hw''' argument is provided only the device identified by this is monitored. Please note that a valid handle will be returned even if there is no matching device for '''user'''.
 
Also, the user handle can be used to create and control calls on behalf of the user.
 
====void UserEnd(integer user)====
 
Frees the handle ''user'' obtained with '''UserInitialize'''. No events will be posted for this user anymore.
 
===Device===
 
For each User object multiple devices can be configured within the PBX. A device reprersents the physical endpoint used for calls (e.g. phones). Any registration to the PBX is associated to a configured device by the name/number used for the registration. Even thou it is possible that one configured device in the PBX accepts multiple registrations, it is recommened to configure the PBX in a way that there is one registration to a device. This way an application can control which physical endpoint is used for a call.
 
====Device[] Devices(int session, string user)====
 
This function returns an array of devices configured for a user identified by its cn (long name). The '''cfg''' flag in '''UserInfo''' is set when this information is changed. The structure 'Device' contains the following members:
 
{|
|valign=top nowrap=true|'''hw'''
|The Hardware Id used to identify the device. This string is used to associate any calls to devices.
|-
|valign=top nowrap=true|'''text'''
|A text configured as a description of the device. It can be used to be presented to the user for the user to select a device.
|}
 
===Call===
A call represents one leg of an existing call in the PBX. 
 
====CallInfo====
The calls attributes are stored in a '''CallInfo''' structure, which has the following elements:
 
*'''int user'''
 
the user handle the call belongs to
 
*'''int call'''
the call handle
 
*'''int reg'''
 
currently unused
 
*'''bool active'''
 
'''true''' if the call exists, '''false''' if not.  The only case where ''active'' can be '''false''' is when a call is terminated. A single '''CallInfo''' event will be posted with ''active'' set to '''false''' then
 
*'''integer state'''
 
A calls state. A bit field made up as follows:
{|
|+
| Value
| Mask
| Meaning
|-
| 1
| 0xF
| setup
|-
| 2 || || setup-ack
|-
| 3 || || call-proc
|-
| 4 || || Alert
|-
| 5 || || Connect
|-
| 6 || || disconnect sent
|-
| 7 || || disconnect received
|-
| 8 ||          || parked
|-
| 0 || 0x80    || inbound  call
|-
| 1 || 0x80    || outbound call
|-
| 0 || 0x100  || active call
|-
| 1 || 0x100  || call on hold
|}
 
Note that the PBX API is PBX-centric, not terminal centric.  As such, it considers a call ''from'' the PBX ''to'' the terminal as ''outbound''.
 
 
*'''string msg'''
A textual representation of the signalling message causing this event. E.g. “'''x-setup'''”.
 
 
*'''No No'''
 
An array of '''No''' records (see below).  This can include information about various peers related to the call itself.  The type of the peer described in an individual '''No''' record is determined by the value of its '''type''' member.  Currently defined values for '''type''' are:
 
**'''peer'''
 
The current remote end of the call (the local end is determined by the UserInfo identified through the user handle above)
 
**'''leg2'''
 
The last diverting user (if any)
 
**'''leg2orig'''
 
The 1st diverting user (if any, from on v8hf18)
 
** '''leg1'''
 
Indicates a call-forward/blind-xfer(?) to the calling end
 
**'''ct'''
 
The last user having transferred the call (if any)
 
*'''Info info'''
 
An '''Info''' record describing various aspects of the call.  The type of the information described in an individual '''Info''' record is determined by the value of its ''type'' member.  Currently defined values for ''type'' are:
 
**'''conf'''
 
A string holding the conference id (a GUID) of the conference the call is a leg of
 
====No Record====
 
Peer information is stored in a '''No''' record with the following elements:
 
*'''string type'''
 
the type of the peer described by the record
 
*'''string cn'''
 
the peer’s PBX’s objects common name (if any)
 
*'''string e164'''
 
the peer’s phone number
 
*'''string h323'''
 
the peer’s h323 alias
 
*'''string dn'''
 
the peer’s display name
 
====Info record====
Various information is stored in '''Info''' records with the following elements:
 
*'''string type'''
 
the type of the information described by the record
 
*'''string vals'''
 
a string value associated with this information (if any, the ''type'' of the element determines if an '''Info''' element has a string or an integer value)
 
*'''integer vali'''
 
an integer value associated with this information (if any)
 
 
 
Note that the call related functions do not return a meaningful value.  This is because the operations success is reflected in the subsequent CallInfo events.
 
 
====integer UserCall(integer user, string cn, string e164, string h323, int reg, InfoArray info, int rc, string srce164)====
 
Creates an outgoing call from the '''user''' (which is a handle obtained by a call to '''UserInitialize''')  to the destination described by ''cn'', ''e164'' and ''h323''.  The argument '''srce164''' may be used to override the calling party number (note that this overrides the callers extension, not the full calling party number). Arguments ''reg'' and ''info'' are currently ignored. The argument ''rc'' is usually 0, unless special behavior is required by using other [[Reference8:SOAP_API#Remote_Control_Facilities|Remote Control Facilities]]. Returns a handle to the call (0 on failure).
 
The called number (''e164'') is interpreted in the context of the user object the call is placed for (''user'').
 
From V8HF3 on, if the srce164 argument of UserCall starts with 'r' or 'R', the call is sent with CLIR (calling line identification restricted).
 
Depending on the nature of the device the user is registered with, the device may actually place the call or the PBX may place a call and once it is accepted, it places another call to the destination.
 
====UserConnect(integer call)====
Connects an existing ''call''.  This forces the device the user is registered with to accept the call.  It may then go into hands-free mode.  Incapable (i.e. non-innovaphone) devices may simply ignore this call.
 
====UserTransfer (int acall, integer bcall)====
''acall'' and ''bcall'' are both calls a single user currently has active.  This method will connect ''acall'' with ''bcall'', leaving the user without both calls.
 
====UserMediaTransfer (integer acall, integer bcall, boolean user, boolean peer)====
 
This function establishes a media connection between two parties currently active in a call independent of the signalling connection. ''acall'' and ''bcall'' are both active (connected) calls. If ''user'' is true, the user sides of the calls are connected together, if ''peer'' is set to true the peer sides of the calls are connected together. If neither ''user'' nor ''peer'' is set the calls are connected to their respective signalling peers.
 
====bool UserRedirect(integer call, string cn, string e164, string h323, InfoArray info, integer rc)====
Places a call to the destination described by ''cn'', ''e164'' and ''h323'' and connects ''call'' to this destination.  Argument ''info'' is currently ignored.
 
The argument ''rc'' is usually 0, unless special behaviour is required by using other [[#Remote_Control_Facilities|Remote Control Facilities]]. Returns a handle to the call (0 on failure).
 
Any call forwarding configured for the destination will be ignored.  See [[Reference8:SOAP_API#bool_UserReroute.28integer_call.2C_string_cn.2C_string_e164.2C_string_h323.29|UserReroute()]] below.
 
====bool UserReroute(integer call, string cn, string e164, string h323)====
Performs a rerouting of the call.  Call forwardings set for the destination will be obeyed.
 
====integer UserPickup(int user, string cn, integer call, string group, int reg, InfoArray info)====
Redirects a call such that it appears as a new call at ''user''. The call to be redirected can be specified by its ''call'' handle.  Alternatively, calls can be picked up by a users ''cn'' or by a ''group'' name.  If all parameters are null, an implicit pickup is done.  The new call handle is returned. Arguments ''reg'' and ''info'' are currently ignored.
 
====UserClear(integer call, integer cause, InfoArray info)====
Disconnects the ''call'' providing ''cause'' as disconnect reason. 
 
Cause is coded as a 7bit integer according to the table found in [[Reference:ISDN Cause Codes]].
Argument ''info'' is currently ignored.
 
====UserCtComplete(integer call, string e164, string h323)====
 
Sends a notification to the device ''call'' is active on that the remote peer has changed to ''e164'' and ''h323''.  This resembles the notification a device may receive if its remote peer transfers the call to the new destination.  The device may update its display and/or call data accordingly.  This call is often used to force the devices (i.e. telephones) display to show application specific data.
 
====UserHold(integer call, bool remote)====
Sets the call on hold.  The device may or may not display the hold status.  In any case, the media channel is disconnected until a UserRetrieve is called.
 
In ''V8 hotfix23'' an additional parameter '''remote''' was added. If set to '''true''', '''remote''' will force to play MOH only to remote user (who is being held), set to '''false''' maintains the default behaviour (MOH played on both, remote and local users). To use this parameter the recent WSDL 8.00 file must be retrieved.
 
====UserRetrieve(integer call)====
Retrieves the ''call'' on hold.  The device may or may not display the new status.  In any case, the media channel is reconnected.
 
====integer UserPark(integer call, string cn, integer position)====
Parks the call at the PBX object '''cn''' and local user on postion '''position'''. A position of -1 means any position is allowed. <!-- The parked call will show up as new call at the user in '''CallInfo''' records returned by '''Poll()''' if the '''xfer''' flag of the corresponding '''UserInitialize()''' call has been set to true. - no, not ture - ckl -- -->The return value is the handle of the new call.
 
To unpark calls, use the returned call handle with the '''UserPickup()''' function.
 
The '''cn''' argument is currently ignored (that is, all calls are parked on the object the call referred to by '''call''' belongs to).
 
====UserDTMF(integer call, bool recv, string dtmf)====
Sends DTMF digits on behalf of the user. If '''recv''' is set to ''true'' the DTMF is sent to the local user.
 
====UserUUI(integer call, bool recv, string uui)====
Sends User-User_information on behalf of the user. If '''recv''' is set to ''true'' the uui is sent to the local user.
 
====UserInfo(integer call, bool recv, string cdpn, string key, string dsp)====
Sends INFO message on behalf of the user. If '''recv''' is set to ''true'' the INFO message is sent to the local user. This function can be used to send overlap dialing information.
 
====UserRc(integer call, integer rc)====
Sends remote control facility to an innovaphone IP phone. It will be ignored by 3rd-party endpoints.
 
This function can be used to establish a three-party conference on an innovaphone IP phone. For this use the function UserRc on an active call using the '''rc''' value 4, while a second call is on hold.
 
===Remote Control Facilities===
A remote control facility can be sent to an innovaphone IP phone to activate additional call handling on the device.
 
The actual set of remote control facility function codes actually depends on the firmware used on the telephone, not the WSDL version used for SOAP.  The current set is documented in [[Reference:Remote Control Facility]].
 
===Messaging===
 
====integer UserMessage(integer user, string e164, string h323, string msg, string src_e164, string src_h323 )====
Sends an message from the '''user''' (which is a handle obtained by a call to '''UserInitialize''') to the destination described by ''e164'' and ''h323''.  The parameters ''src_e164'' and ''src_h323'' may be used to override the calling party's information, in order to present a different callback information to the recipient of the message. Returns a handle to the call (0 on failure), which can be used to track the delivery of the message. A event of type 'msg-sent' indicates the delivery of the message.
 
===Status Retrieval===
 
Instead of monitoring calls using the ''Poll'' mechanics, there are some functions to retrieve the current at a certain point in time.
 
====CallInfo[] Calls(integer session, string user)====
Returns an array of '''CallInfo''' records for the calls currently active at the registration defined by ''user''.  Please note that this function may be called without having called '''UserInitialize ()''' before.  Thus, the call handle information in the '''CallInfo''' records returned is meaningless.
 
====UserInfo[] FindUser(string v501, string v700, string v800, string cn, string h323, string e164, integer count, integer next)====
Returns an array of at most ''count'' '''UserInfo''' records for the users matching ''cn'', ''h323'' or ''e164''.  Only one of ''cn'', ''h323'' and ''e164'' may be specified, except that ''e164'' and ''cn'' may be specified. In this case the number in ''e164'' is interpreted in the Node of the user specified with ''cn''.  The search string will be used as a starting point into the alphabetically sorted list of objects, that is, a search for “'''A'''” will yield entries starting with “'''A'''” but also – depending on ''count'' – the following entries.  Neither search string may be empty.  v501, v700 must be set to a non-empty value.
 
To call '''FindUser''', no session is required, however, you need a valid HTTP authentication.
 
Be aware that large values for ''count'' may fail and even crash the PBX.  If you need to retrieve the whole user list, you should be using 50 as  ''count'', provide the last ''cn'' retrieved as new start cn and loop until ''''FindUser''' returns no more results, passing '''true''' as  value for ''next'' for all but the first calls.
 
The '''UserInfo''' records returned by '''FindUser''' will contain an empty ''loc'' attribute if the registration PBX of the user returned is identical to the PBX the '''FindUser''' was sent to.
 
====string License(integer session, string name)====
This function is for internal use only.
 
====string LocationUrl(string v501, string v700, string location)====
Returns a string with the HTTP URL for the PBX named location to which a SOAP session can be created. Typically, location  is retrieved from the ''vals'' element of an '''Info''' record with ''type'' '''loc''' in an '''UserInfo''' record.  ''location'' needs to be specified as the '''h323''' attributes value of the PBX node '''UserInfo''' data you are interested in.
 
Please note that LocationUrl will not report the correct URL if the target PBX is a dynamic PBX.
 
===Administration===
The SOAP interface can be used for administrational purposes also.  This is done via the Admin call.
 
====string Admin(string xml)====
 
Sends the administrational command ''xml'' to the PBX.  The command is executed and any result is returned. 
 
This command allows you to query and modify the PBX object configuration (e.g. to query and set a users call forwarding).  The scope and format of the commands valid for ''xml'' is beyond the scope of this document, however, there is a separate article on that (see the [[Reference8:SOAP_API#Related_Articles|Related Articles]] below).
 
To call '''Admin''', no session is required.  However, you must be authenticated as an admin user on the underlying HTTP layer.
 
==Typical design of a PBX SOAP Application==
Please refer to the [[Reference:SOAP_API_%28pbx501.wsdl%29#Typical_design_of_a_PBX_SOAP_Application|pbx501.wsdl]] article for a discussion of the typical design of a SOAP application.
 
==References==
The wsdl definition is available [http://www.innovaphone.com/wsdl/pbx700.wsdl here].
 
==Known Problems==
Please read [[Howto:Authentication in the SOAP interface]] in case you have problems to authenticate SOAP access.
 
==System Requirements==
The PBX SOAP API requires a working PBX.
 
To work with the PBX API in this version, you must run at least version 7.00 software on your PBX.  Also, you must run at least version 5 software on the phones.
 
==Installation==
There is no specific installation required, as the PBX API is integral part of the PBX (although licenses are required to operate the PBX).
 
==Configuration==
To prepare an PBX for PBX API testing
*setup a separate PBX
*install current firmware (at least 8.00)
*configure the PBX as usually
*add an user object called '''API''' , define a ''password'' for this object
*create a new group (e.g. called '''all users'''), by adding a group tag to '''API''', make it ''active''
*add a similar group tag to all other test users
*call '''Initialize()''' and use '''API''' as user and '''API''' and its ''password'' as http credentials
 
==Related Articles==
[http://wiki.innovaphone.com/index.php?search=soap Search for articles about SOAP]
 
<!-- keywords: sopa -->

Latest revision as of 15:34, 10 May 2013

Redirect to:

Retrieved from "https://wiki.innovaphone.com/index.php?title=Reference10:SOAP_API&oldid=29566"