Contact person: Business Client

Phone:Show

Email:Show

Location: Baton Rouge, United States

Budget: Recommended by industry experts

Time to start: As soon as possible

Project description:
"Develop a windows service (Linux is potentially acceptable but additional discussion needed) using Avaya resources and compatible TAPI libraries or Avaya DevLink IP Office API, and similar integration programs that may be available programs to facilitate dialing automation (utilization of one is needed, not support for all, this is a non inclusive list of ones the client believes may be possible to research or use).

Client desires the capability for 2-3 different private in house applications to initiate phone calls from physical phone extensions attached to the IP Office Phone system saving its users from directly dialing and enabling additional CRM platform use (the call should indicate as if the user dialed the call from the provided extension, however, if needed to ring the phone/identified and wait for pickup before starting the outside call dial, that is acceptable, please provide potential options and flows to client for discussion). Users will not have normal desktops or assigned workstations which makes desktop software untenable. Endpoint extensions will be logged in to the phone system and online; our end users do not log-in/log-out of extensions. Within applications, users do not want soft phones or any type of in app or RTC client. Client desires a simplistic rest style API to accept an extension and outbound dial number and the service to handle the phone system work; the application developers for internal applications should remain abstracted from the Avaya technical program: no Avaya SDK’s, drivers or telephony logic should be required by call initiating applications.

Client is running Avaya IP500 V2 version [login to view URL] build 18. Upgrade to a newer version can be performed / evaluated if needed but is not preferable, would like to see a POC first before initiating upgrade activities through Avaya partner. A successful proof of concept would be a demonstration or video (by contractor) of an application such as postman or curl request to a developmental component of the requested solution that visibly shows an Avaya phone dialing the number provided by postman/curl request.

Client licensing is as follows. Additional licensing can be acquired and installed if needed.
License Type Available Instances
CTI Link Pro 1
Wave User 1
Additional Voicemail Pro (ports) 14
3rd Party IP Endpoints 21 (20 reserved)
SIP Trunk Channels 40
Avaya IP Endpoints 260
Power User 17
Essential Edition 1
R8+ Preferred Edition (VM Pro) 1

Client will NOT provide dev or test access to their phone system. Contractor must have suitable test environment and lab resources along with any appropriate Avaya credentialing on their own. Client is willing to discuss environmental factors with developer to work toward the application deliverable.

Application expectations / requirements:
- One or more private internal applications use a simple rest API to call a web service, running as a service (for production) hosted in the same network as the client’s Avaya IP 500V2 Office.
- Application utilizes Avaya drivers, frameworks, SDK’s to trigger the requested extension to go off hook and dial the provided phone number. Discuss / review with client options and confirm availability prior to finalizing bid and starting work.
- IF POSSIBLE to return a call ID and/or correlation ID that would also show in SMDR logging applications, that is ideal but is not required.
- Application logs should be written to a log directory, to be defined by configuration with built in rotation / new log file to start daily / at change of date.
- Application will be deployed on an internal server targeting our internal phone system and used by internally hosted applications, the application will not have public web exposure and while additional security, logging and rate limiting factors may need to be added later, for initial development and deliverables, advanced security features and rate limiting are not required. Addition of security features, advanced logging and rate limiting will be considered in future phases or development of this project.

During development, testing and initial acceptance phases, the application can run as a windows desktop application for debugging and easy start/stop/review. Final delivered version should include ability to run as a windows service without an active user logged in.

Deliverables should include:
- Links or direction to download any required drivers or applications from Avaya. Customer / client has access to Avaya systems and an Avaya support partner. Developer is not being asked to provide any restricted software client is not otherwise entitled to.

- Directions on provisioning users or setup in their Avaya IP office or obtaining keys or authorizations for application to work.

- Source code for developed software, do not deliver executable. Client will inspect source and compile. Client has Visual Studio Enterprise 2026 available.

- Sample API calls for testing suitable to hit developed application from swagger, postman or similar.





Overly Simple API call that we would want an application to make:
POST [login to view URL] HTTP/1.1
Host: [login to view URL]
Authorization: Bearer sample-token-12345
Content-Type: application/json
Accept: application/json
{
"fromExtension": "1234",
"dialNumber": "918008675309"
}

Developer and middle-ware application can assume a full dial string will be included which will follow the call routing defined. In the sample request, the application would trigger whatever outbound call route is defined by dialing 9. CRM / applications will build / compile complete call number string; while not anticipated, there could be situations where an internal number is called.
In cases where an extension is busy, not online or otherwise cannot be triggered, a set of error codes should be passed back in real time." (client-provided description)