The purpose of Openlink is to provide a simple way of doing Computer Telephony Integration (CTI) with XMPP Applications by specifying a profile of XEP-0050: Ad-Hoc Commands, associated XEP-0244: IO Data and XEP-0060: Publish-Subscribe instead of defining an XML messaging telephony protocol like CSTA over XMPP as a new specialized and distinct XMPP protocol extension.
Openlink uses XEP-0244: IO Data Input and Output data structure to specify the complex data required as input and output for telephony Ad-Hoc commands. Openlink also uses XEP-0060: Publish-Subscribe to route the event messages generated by telephony call or device state changes from the telephony service to all interested parties.
This document addresses the following requirements:
A Telephony Service Provider (TSP) XMPP component MUST advertise any service commands it supports via XEP-0050 (as described in XEP-0050: Ad-Hoc Commands).
In order to interact with a particular TSP component attached to an XMPP server, an application developer's user agent application MUST first discover that component, the commands and IO Data structures it supports, then send the appropriate command to the component itself. An XMPP server SHOULD NOT process commands on behalf of associated components, just as it does not handle service discovery requests on behalf of such components.
Openlink uses version numbers in it's namespace. This ensures it remains an evolving standard with fixed (but easy to discover) features on each version. Each TSP CAN support as many versions as possible. It is recommend that three versions on a rolling basis (previous, stable and beta) SHOULD be supported. Useragent applications SHOULD be designed for a specific version and CAN use a binding tool to generate a language specific class libraries for the IO Data structures.
The available Openlink versions (commands and structures) will be discovered by standard XMPP service discovery because the namespace is qualified by version numbers. The granularity of Ad-Hoc commands service discovery will enable user-agent applications to selectively pick commands and supporting IO Data structures from different versions in order to be backwards or forwards compatible with TSP implementations.
This document defines Openlink version 1.0.0, a profile of XEP-0050: Ad-Hoc Commands requests and supporting XEP-0244: IO Data that a user agent application can initiate to a TSP in order to recieve XEP-0060: Publish-Subscribe messages that will enable the following use cases:
Openlink uses profiles, interests and features to enable a user agent application use a TSP without in-depth knowledge of the underlying telephony resources.
An Openlink end-user may have a single default profile or multiple profiles depending on the capabilities of the devices and services available to them.
An Openlink interest represents a directory number or direct line that a user is interested in. An end-user could have by default, a single directory number or a whole range of directory numbers and direct lines depending on the active user profile. A direct line on the other hand, is a sharable hard (TDM) or soft (VOIP) dedicated connection between a group of users.
A feature is telephony software or hardware feature that can be used on the profile telephony device or call to enhance the user experience. For example, something hardware like a second handset, an independent speaker unit or software like a voice message, call forwarding, a speed dial or ability to make a call private or public. A user could have by default a single handset and integrated speaker unit.
The user agent application does not need to know the details of a user profile, interest or feature, but should be able to query the TSP for a list of user profiles, associated user interests and features in order to present them to the user interface and enable the user make a choice. User profiles interests and features are IO data objects required by Openlink commands.
Note: The text that follows assumes that implementors have read and understood XEP-0050: Ad-Hoc Commands, XEP-0244: IO Data, XEP-0060: Publish-Subscribe and know how to discover an XMPP component like 'openlink.shakespeare.lit'.
To enable a user agent application fetch user profiles on behalf of an end user, the fully qualified XMPP JID of the end user MUST be provided. The TSP can keep a mapping of JIDs to any required internal user identity scheme adopted by the TSP. This command is NOT a batch command and must be issued explicitly for each end-user.
The command node for this use case SHOULD be "http://xmpp.org/protocol/openlink:01:00:00#get-profiles".The output is a list of profiles. Each profile contains the profile id, device identification, label and optional default and online attributes. The online attribute is a flag that is set true when the end user is logged into a device somewhere with this profile. Also included, is a list of available telephony actions for the profile. Each action will contain the action id and label attributes.
The list of actions potentially supported include:
A sample protocol flow for this use case is shown below.
Unless an error occurs (see the Error Handling section below), the TSP SHOULD complete the command and return the appropriate output IO Data.
In many cases, a user profile is associated with a real physical device and it is often required to implement a softphone version of this device, In such situations, a user agent application can fetch the device details of a profile on behalf of an end user with this command. The details returned in the output will depend on the device type and the device vendor. The command node for this use case SHOULD be "http://xmpp.org/protocol/openlink:01:00:00#get-profile".
The output is a device element with a namespace "http://xmpp.org/protocol/openlink:01:00:00/profile/xxxx" where xxxxx is the device attribute of the profile. The contents is any well-formed XML that uniquely associated with the namespace.
A sample protocol flow for this use case is shown below.
Unless an error occurs (see the Error Handling section below), the TSP SHOULD complete the command and return the appropriate output IO Data.
To enable a user agent application fetch user interests, a user profile must be provided.
The command node for this use case SHOULD be "http://xmpp.org/protocol/openlink:01:00:00#get-interests".The output is a list of interests. Each interest contains the interest id, type, label with optional default and fwd attributes. The default attribute value is either true or false. The fwd attrbute reports any call active forwarding destination for the interest. The list of interest types supported include:
If there are any active calls for an interest, then the interest element will also have a child callstatus element which will have a list of child call elements. Each call element will represent an active call for the inerest. See Make Call output for details of <callstatus>.
A sample protocol flow for this use case is shown below.
Unless an error occurs (see the Error Handling section below), the service SHOULD complete and return the appropriate output IO Data.
In the following example 'callstatus' is included for those interests which currently have active calls.
To enable a user agent application fetch a specific single user interest, the interest must be provided.
The command node for this use case SHOULD be "http://xmpp.org/protocol/openlink:01:00:00#get-interest".The output is the requested interest element contained within a interests element. See Get Interests output for details of <interest>.
A sample protocol flow for this use case is shown below.
Unless an error occurs (see the Error Handling section below), the service SHOULD complete and return the appropriate output IO Data.
To enable a user agent application fetch telephony device features available to a user when using a specific profile. Modifiable device feature can be changed explicitly with the Set Feature command or implicitly with telephony commands. An example would be the "PrivateCall" action which changes the privacy attribute of a call. The profile id must be provided as input.
The command node for this use case SHOULD be "http://xmpp.org/protocol/openlink:01:00:00#get-features".The output is a list of features. Each feature contains the feature id, type and label. The list of feature types potentially supported include:
* Device features not modifiable
A sample protocol flow for this use case is shown below.
Unless an error occurs (see the Error Handling section below), the service SHOULD complete and return the appropriate output IO Data.
In order to recieve notifications of telephony call events, a user agent application MUST subscribe for Openlink events using XEP-0060: Publish-Subscribe (pub-sub). Openlink interests are represented as pub-sub leaf nodes. (See XEP-0060: Publish-Subscribe). The user agent application must explicitly subscribe for interest leaf nodes or self-created collection nodes that contain interest leaf nodes. A user agent can only subscribe on behalf of an end-user for interests provisioned to the end-user recieved by the TSP with a Get Interests command.
Subscribing for Openlink interests telephony call events implies subscribing for events relating to the device that the interests are associated with.
A sample protocol flow for this use case is shown below.
If the subscription request is successfully processed, the pub-sub service MUST inform the user agent that it is now subscribed for the interest node (which MAY include a service-generated SubID).
The current state of all active calls for the subscribed interest WILL be immediately pushed by the pub-sub service to the user agent.
To initiate a outbound call, the user agent application has to provide the end user JID, optional destination, user interest and list of features. The user default interest and features will be used if not provided and the destination is only required when the user interest is a directory number line. It is not required if the interest is a direct line or a speed dial is included in the list of features.
Feature Type | Purpose | value1 | value2 |
---|---|---|---|
SpeedDial | Speed dial to be used as destination of call | ||
VoiceMessage | Voice message to be played after call is established | ||
MicrophoneMute | Mute/unmute microphone when call is established | 'true' or 'false' | |
SpeakerMute | Mute/unmute speaker when call is established | 'true' or 'false' | |
SpeakerChannel | Put call on speaker channel after call is established | 'true' or 'false' | |
Privacy | Set the device privacy after call is established | 'true' or 'false' | |
Handset | Set the device active handset to be used for the call | 'true' or 'false' | |
CallBack | Set callback destination for remote handset to be used for the call | 'true' or 'false' | Telephone Number |
Conference | Indicates that conference resources should be allocated for the call in order to support line sharing actions | 'true' or 'false' |
The namespace for callstatus SHOULD be 'http://xmpp.org/protocol/openlink:01:00:00#call-status'.
The changed code indicates which call attributes changed and caused the new call status message to be published.Changed code | Description |
---|---|
State | A change in telephony call state. |
Actions | A change in valid telephony actions without a call state change. |
Participant | A change in participation without a call state change. |
Caller | A change in caller details. |
Called | A change in called details. |
Privacy | A change in the call privacy. |
VoiceMessage | A voice message feature event. |
State name | Description |
---|---|
CallOriginated | Indicates to an end-user initiating a call that a telephony line is allocated and gone off hook. |
CallDelivered | Indicates to an end-user initiating a call that the destination is ringing. |
CallEstablished | Indicates to an end-user initiating a call that the destination has answered the call. |
CallFailed | Indicates to an end-user initiating a call that the destination has rejected the call. |
CallConferenced | Indicates that a call now has multiple active participants or multiple far parties. |
CallBusy | Indicates to a peer end user that a call is now active and available to join subject to privacy. |
CallHeld | Indicates a call is held on the caller device. |
CallHeldElseWhere | Indicates a call on a shared interest is held elsewhere and can be retrieved by the user. |
CallTransferring | A call transfer is in progress. |
CallTransferred | A call transfer has been made. |
ConnectionBusy | An interested peer call is offhook elsewhere. |
ConnectionCleared | A call has ended on the caller device. |
CallMissed | A caller stopped ringing before anyone could answer. |
Element | Description | Values |
---|---|---|
recnumber | The voice recording number | Number |
recport | The voice recording port allocated | Number |
recchan | The voice recording channel | Text |
rectype | The voice recording type | Text |
The namespace for voicerecorder SHOULD be 'http://xmpp.org/protocol/openlink:01:00:00/features#voice-recorder'.
Element | Description | Values |
---|---|---|
microphone | The microphone stream name | Text |
speaker | The speaker stream name | Text |
The namespace for mediastream SHOULD be 'http://xmpp.org/protocol/openlink:01:00:00/features#media-stream'.
Each individual call has a list of valid actions that can be requested for while the call remains in its current state and holds its current attributes.
The command node for this use case SHOULD be "http://xmpp.org/protocol/openlink:01:00:00#make-call".
A sample protocol flow for this use case is shown below.
Unless an error occurs (see the Error Handling section below), the TSP SHOULD process the telephony action.
The request is then handled by the TSP CTI engine which in turn will begin to push out telephony events for the end user to the user agent as they occur. The events are delivered though standard XEP-0060: Publish-Subscribe notifications.
Each event notification item will consist of a list of pub-sub items. Each item can contain either a devicestatus device event details or a callstatus list of call event details.
A devicestatus event consists of the active profile and a list of features. Each feature will have an id attribute and an optional child element with an identifying namespace depending on the type of feature. For example, voice messages have a child element called voicemessage. See Manage Voice Message for details. Features which effect the overall user experience without affecting a specific call are shown as device events are published to the default interest of the user's active profile.
The user agent application can now request any valid action for the end-user. The user agent application does not need any assumed knowledge about the actions and what they really do. That can be passed on to the user interface for the end-user to decide which action to take. The user agent application can check the user profile for a complete list of actions supported (see the Get Profiles section below). The action labels can be used to influence the user interface
Action | Description | value1 | value2 |
---|---|---|---|
AnswerCall | Answers an alerting call on active profile device | ||
ClearConference | Clears an active local conference on the device | ||
ClearConnection | This request allows the active profile device to be released from a call. In the case of a normal two-party call the entire call will be cleared, but in the case of a multi-party conference this request will cause just the specified device to be removed from the conference, and if the active parrticipants count is down to two, then the call will revert to a normal two-party call. | ||
ClearCall | Forces all participants off call and disconnects the far party. | ||
ConferenceCall | Conferences an existing active call to a local conference bridge on the device. | ||
ConsultationCall | Places an existing active call effectively on hold and initiates an new call to the supplied Destination in Value 1. It is often used as a precursor to the TransferCall action. Consultation Call with no destination, will cancel an ongoing Consultation Call and resume the original call | Telephone Number | |
StartVoiceDrop | Starts playing a pre-recorded voice message or playlist into the active call. | Voice message or playlist feature Id | |
StopVoiceDrop | Stops playing a pre-recorded voice message or playlist on the active call. | VoiceDrop message or playlist feature Id | |
HoldCall | Put the active call on hold. | ||
PrivateCall | Make the active call Private. This also activates the privacy feature for the call | ||
PublicCall | Make the active private call Public. This also deactivates the privacy feature for the call | ||
IntercomTransfer | Transfer the active call to internal user by name. | JID of transfer target | |
JoinCall | Join an active call elsewhere and make it a conference call by becominging an active participant. | ||
AddThirdParty | Add a third party destination to an active call and make it a conference call | Telephone number | |
RemoveThirdParty | Remove a third party destination from an active call | Telephone number | |
RetrieveCall | Retrieve a call on hold. | ||
TransferCall | Complete a transfer started with ConsultationCall. Release the active profile device from the call. | ||
SingleStepTransfer | Transfers a call without first using the ConsultationCall action. This allows a call to be transferred in a single step, without putting the original call on hold. | Telephone Number | |
SendDigits | Causes dial digits to be sent on an originated call on the active device. Used to make a call in two steps by first selecting a specific or default interest and dialing the phone number when dial tone is available and call is in the originated state. | Telephone number | |
SendDigit | Causes a DTMF tone to be sent on an existing call at active device. | Telephone digit |
Following example illustrates an active participant putting the call on hold. The user agent application requests for a command next action with an input Openlink IO Data structure. All other actions are similiar to the following examples shown below.
Unless an error occurs (see the Error Handling section below), the service SHOULD process the action.
The user agent application requests for action='answerCall' on behalf of a user who answers the call. That user will become an active participant while others remain inactive.
Unless an error occurs (see the Error Handling section below), the service handles the requested action.
When the call terminates, the TSP notifies the user agent application with a ConnectionCleared]]> element.
This command is used to initiate a outbound call directly to another user with an XMPP identity, the user agent application has to provide the end user JID, the target user JID and an optional list of features. The destination is optional and will be ignored if a GroupIntercom feature is included in the list of features.
The command node for this use case SHOULD be "http://xmpp.org/protocol/openlink:01:00:00#make-intercom-call".
A sample protocol flow for this use case is shown below.
Unless an error occurs (see the Error Handling section below), the TSP SHOULD process the telephony action and publish the appropriate telephony events.
This command is used to perform service management of voice messages that can be used with the StartDropVoice request action. See Request Action. Depending on the TSP, this command may initiate an incoming or outgoing call to or from the voice message recorder service to perform the required action.
Action | Description | Label | List of Features |
---|---|---|---|
Create | Create a voice message playlist | Playlist label | |
Record | Records a new message to replace any existing message. The old message is kept for audit purposes. | Message label | Single Feature |
Edit | Replace only the voice message or voice message playlist label. | Message label | Single Feature |
Playback | Playback recorded messages or voice message playlists | ||
Save | Save recorded messages | ||
Archive | Move voice messages from the online store to the offline store. | ||
Delete | Delete voice messages or a voice message playlists | ||
Query | Return the details of voice messages or playlists |
Element | Description | Values |
---|---|---|
msglen | The length of the voice message in seconds | Number |
status | Status of voice message after action | ok,error,warn,unknown |
statusdescriptor | Textual description of status | Text: record,playback,voicedrop |
state | The current state of voice message due to action | start,stop |
sequence | The sequence number of the message in a playlist. For solo messages, it will have value 1 | Number |
amdetect | Flag indicationg if an answer machine was detected at the far party | true, false |
exten | The internal telephone number associated with the voice message | Dialable telephone number |
creationdate | The creation date of the voice message | Date |
The namespace for voicemessage SHOULD be 'http://xmpp.org/protocol/openlink:01:00:00/features#voice-message'.
The command node for this use case SHOULD be "http://xmpp.org/protocol/openlink:01:00:00#manage-voice-message".
A sample protocol flow for this use case is shown below.
Unless an error occurs (see the Error Handling section below), the TSP SHOULD process the Voice Message action and return a response.
The voice message response will include a feature Id for the new voice message as well as a telephone extension which can be used with the Make Call command to call the voice message IVR system to actually record the message. Voice message devicestatus event messages will pushed to the default interest of the active user profile to notify the user of the recording progress.
Unless an error occurs (see the Error Handling section below), the TSP SHOULD process the Voice Message action and return a response.
Unless an error occurs (see the Error Handling section below), the TSP SHOULD process the Voice Message action and return a response.
This command is used to provide voice bridging. This is the ability of a third party to initiate and manage calls between a first and second party or between multiple parties. The voice bridge can either bridge calls directly between two call participants or use internal audio conferences to bridge multiple call participants. These internal conferences are dynamic in nature and their management is outside the scope of this specification. The voice bridge also requires the TSP to have a reserved pool of reusable dynamic interests that can be leased on demand to service the call control requirements of voice bridging.
The command node for this use case SHOULD be "http://xmpp.org/protocol/openlink:01:00:00#manage-voice-bridge".Action Name | Description | 1st Input | 2nd Input |
---|---|---|---|
SetPhoneNo | Specify the phone number of a participant | Participant Id | Phone Number |
SetConference | Associate a conference with a participant | Participant Id | Conference Id |
SetIncomingInterest | Associate an Openlink Interest with a participant for incoming calls. | Participant Id | Interest Id |
SetOutgoingInterest | Associate an Openlink Interest with a participant for outgoing calls. | Participant Id | Interest Id |
Set2ndPartyPhoneNo | Associate a second party phone number with a participant to be used with an outgoing interest. | Participant Id | Phone Number |
MakeCall | Bridge an outgoing call between a participant and a second party or a conference | Participant Id | |
BridgeCall | Bridge any incoming call to a participant's interest with a second party or a conference. | Participant Id | Caller Id |
SendDTMF | Send DTMF to second party | Participant Id | DTMF key |
TransferCall | Transfer a participant to another conference | Participant Id | Conference Id |
MigrateCall | Migrate a participant to a new phone number | Participant Id | Phone Number |
RedirectCall | Redirect a second party to a new phone number | Participant Id | Phone Number |
PlayVoiceMessage | Play a voice message to a second party or all other participants in a conference | Participant Id | Voice Message Feature Id |
CancelCall | Terminate a participant's call | Participant Id |
There is no output unless an error occurs (see the Error Handling section below)
Voice Bridge call event events are published as pubsub <voicebridge> messages to the user jid node name with the identifying namespace "http://xmpp.org/protocol/openlink:01:00:00/features#voice-bridge". The voice bridge voicebridge event will consist of the following details of the voice bridge call event.Element | Description | Values |
---|---|---|
jid | Requesting user JID | JID |
eventtype | The event type | state_changed, timeout, migrated, migrated_fail, transferred, started_speaking, stopped_speaking, dtmf_key |
dtmf | DTMF key pressed | 0-9, *,# |
participants | Number of Participants | Numeric |
callstate | New state for state_changed event | invited,answered,established,ending,ended |
conference | Conference Identifier | Alphanumeric |
participant | Participant Identifier | Alphanumeric |
callinfo | Additional call information | Text |
eventinfo | Additional event information | Text |
The command node for this use case SHOULD be "http://xmpp.org/protocol/openlink:01:00:00#manage-voice-bridge".
A sample protocol flow for this use case is shown below.
Unless an error occurs (see the Error Handling section below), the TSP SHOULD process the Voice Bridge actions and return an empty response.
Unless an error occurs (see the Error Handling section below), the TSP SHOULD process the Voice Bridge actions and return an empty response.
Assuming that the User Agent subscribes to pubsub nodes of the requesting user (alan.trader@shakespeare.lit), then then the following call event messages will be recieved when the calls get bridged.
This command is used to enable a user agent application manage dynamic directory number interests. Dynamic interests are allocated to end-users on demand from a reserved pool by the TSP. The allocation period is controlled by a lease which allows interests to be allocated for immediate use, session use or indefinite use. An indefinte lease will require an explicit deallocate action while immediate and session leases will expire after a timeout and user logoff respectfully. Dynamic interests will be mostly used for third party call control like voice bridging.
The command node for this use case SHOULD be "http://xmpp.org/protocol/openlink:01:00:00#manage-interests".The output is the requested interest element contained within a interests element. See Get Interests output for details of <interest>.
A sample protocol flow for this use case is shown below.
Unless an error occurs (see the Error Handling section below), the TSP completes the request and returns an allocated dynamic interest
Unless an error occurs (see the Error Handling section below), the TSP SHOULD process the Voice Bridge actions and return an empty response.
This command is used to change the value of a modifible Openlink device feature on behalf of an end-user. The feature id must be provided as input as well as any additional parameters required to activate the feature.
The command node for this use case SHOULD be "http://xmpp.org/protocol/openlink:01:00:00#set-features".Input value2 is only applicable for CallForward, CallBack and SoftPhone.
Feature Type | Description | value1 | value2 |
---|---|---|---|
MessageWaiting | Status of the device message waiting indicator | 'true' or 'false' | |
MicrophoneMute | Status of the microphone mute | 'true' or 'false' | |
SpeakerMute | Status of the speaker mute | 'true' or 'false' | |
SpeakerChannel | Activate/deactive speaker channel for active call | 'true' or 'false' | |
RingerStatus | Status of the device audible ringing | 'true' or 'false' | |
Privacy | Set device privacy | 'true' or 'false' | |
Handset | Set device active handset | 'true' or 'false' | |
DoNotDisturb | Status of device DND | 'true' or 'false' | |
MicrophoneGain | Set microphone volume | Microphone volume(percentage) | |
CallForward | Set call forwarding | Interest Id | Telephone Number. When provided, it specifiies the destination for the call forwarding and when omitted, it specifies that call forwarding is disabled. |
CallBack | Set callback for remote handset | 'true' or 'false' | Telephone Number |
Conference | Indicates that conference resources should be allocated for the call in order to support line sharing actions | 'true' or 'false' | |
SoftPhone | Device features can be simulated | Device feature id to be set (depends on device) | Value to be set |
A sample protocol flow for this use case is shown below.
Unless an error occurs (see the Error Handling section below), the TSP completes the request. There is no output IO Data.
This command is used to enable a user agent application query the status of all telephony device features on behalf of an end-user.
The command node for this use case SHOULD be "http://xmpp.org/protocol/openlink:01:00:00#query-features".A sample protocol flow for this use case is shown below.
Unless an error occurs (see the Error Handling section below), the TSP completes the request. The current status of each device feature is returned as output IO Data.
This command is used to enable a user agent application retrieve stored call records on behalf of an end-user.
The command node for this use case SHOULD be "http://xmpp.org/protocol/openlink:01:00:00#get-call-history".A sample protocol flow for this use case is shown below.
Unless an error occurs (see the Error Handling section below), the TSP completes the request. The specified call records are returned as output IO Data.
Several error conditions are possible when an entity sends a command request to the TSP, as defined in the following table. If one of these error conditions occurs, the TSP MUST return an error stanza to the requesting entity.
Condition | Cause |
---|---|
Conflict | The command cannot be completed because of a data or system conflict (e.g., an interest is already active). |
Feature | The specific command is not supported (even though the ad-hoc commands protocol is). |
Forbidden | The requesting entity does not have sufficient privileges to perform the command. |
Not Allowed | No entity is allowed to perform the command (e.g., retrieve the CEO's interests). |
Unavailable | The ad-hoc commands protocol is not supported. |
For the syntax of these errors, see XEP-0086. Naturally, other errors may be returned as well.
It is possible that a single Openlink TSP will support multiple and different telephony services. This may may be needed when mutiple telephone vendors are used
within a single enterprise. In such senarios, it is recommended that the underlying telephone service components (TSC)s be implemented as XMPP components as well so that they
can be discovered by the Openlink TSP using normal XMPP Service Discovery.
A telephone service should advertise itself as a feature with the following Openlink TSC namespace
http://xmpp.org/protocol/openlink:01:00:00#tsc
In order to associate Openlink TSCs with end users, it is recomended that XEP-0049: XMPP Private Storage be used. Each user will have <openlink> element with the Openlink TSC namespace containing a list of TSCs that support the user. Each Openlink TSC will update the list as required and the Openlink TSP will read it on demand.
Rsponse back for the XMPP server
It may also be required to support both a real Openlink TSP and a simulator for testing and developent on the same XMPP server. In such a case the
Openlink Telephony Simulator (TSS) should advertise itself as a feature with the following Openlink TSC namespace
http://xmpp.org/protocol/openlink:01:00:00#tss
It is the responsiblity of the user agent client to filter event messages. If server-side filtering is required in the TSP, then pub-sub content filtering should be considered and implemented.
IO Data enables the automation or auto-generation of a language wrapper for an Application Programming Interface (API) with an Openlink TSP. Below is an example to show how.
It is the responsiblility of the TSP to create pub-sub nodes for user interests and publish items to them. The TSP can use additional features like watch lists or other telephony confguration parameters to apply filters to the list of interests. This is most relevant to a trading system where hundreds of lines could be accessible to a single trader.
The following pub-sub configuration parameters are required.The ability to perform the TSP request specified herein MUST NOT be granted to user agent applications who lack service-level administrative privileges.
This document requires no interaction with IANA.
The Registrar shall include the following information in its registries.
The XMPP Registrar includes "http://xmpp.org/protocol/openlink:01:00:00" in its registry of protocol namespaces.