[Index]
To access the latest documentation, go to Documentation and Resources at: https://voss.portalshape.com
The VOSS phone server provides a method of hosting SIP compliant devices such as phones and softclients where it is not possible or desirable to connect these devices into other vendor platforms.
In an HCS environment, full integration management is provided where all trunk and dialplan related configuration is automatically applied. Other CUCM dialplan designs may be utilised through the VOSS4UC dialplan additions templating feature.
The VOSS Phone Server provides three functions:
A SIP registrar allows the use of SIP devices from any compliant vendor, thereby allowing for a wide choice of phones with various feature sets, including the re-use of existing devices from systems such as Cisco Unified CM and others. Since the registrar requires only account definition per line, there is no phone concept in the Phone Server itself. Phones are represented in VOSS-4-UC and are a local construct only.
A SIP Switch handling SIP call traffic. Calls between phones hosted on the VOSS Phone Server are handled locally and calls to other extensions or PSTN destinations are offloaded over a SIP Trunk
Configuration File Management (Optional). Phone configuration files may be created and hosted in the VOSS Phone Server's tftp server. This allows unconfigured phones (i.e. new unused phones, or factory defaulted old phone stock) to obtain their configuration automatically when connected to the network.
Sample configuration files for phones from SNOM, Grandstream and Cisco are included.
VOSS-4-UC utilities include:
The VOSS Phone Server is deployed as an OVA, typically alongside CUCM Virtual Machines in an HCS/CUCM environment. Redundancy is an option, providing data replication between servers.
Adding phones requires three areas of configuration. These are all automated by VOSS-4-UC during the phone addition:
Set up call routing
In HCS mode, the CUCM dial plan is created to provide call routing of the chosen numbers towards VOSS Phone Server. This allows incoming call routing. Outbound calling Class of Service and routing are also configured to allow internal extension and E164 call routing. Number inventory and CLI management through transformation patterns are maintained.
Set up the VOSS Phone Server
VOSS Phone Servers are managed on the customer hierarchy - verify that you are at the customer hierarchy.
Version: there is currently only 1.0.0 (base release version).
Deployment Mode: two options are available:
If the HCS deployment mode is selected, the HCS CUCM must be selected.
Network Addresses:
The SERVICE_PROVIDER_SPACE IPv4 address is the address as viewed from VOSS-4-UC, so could be an address viewed through NAT.
The APPLICATION_SPACE IPv4 addresses is the local address of the Phone Server in the customer network.
Both addresses are required, even where the address is the same as would be found if NAT was not in use to provide access from the service provider network.
Virtual Machine: name is optional and is used for administrator data purposes. It is not used by VOSS-4-UC.
Add country support.
Country support must be added in HCS mode in order to integrate with the HCS dialplan. A template is required for each supported country. GBR and USA are provided by default, and other countries may be created or provided by VOSS as required.
To add HCS country support, use the "phone server countries" menu item and select the template for the required country. There are no user parameters required.
Configure the physical phone
In HCS mode, sites must be created with site dialplan and number inventory in the same way as when using Cisco Phones registered directly to CUCM. It is possible to host both CUCM and Phone Server phones at the same site.
The phone itself requires configuration in order to register and handle calls.
Soft clients will likely be manually configured locally on the hosting PC, and a "generic soft client" device type allows for locally configured devices.
Other hardware devices such as phones from SNOM, Cisco and Grandstream may be configured using configuration files hosted on the VOSS Phone Server and downloaded at start up by the phone. TFTP is used to download these files. VOSS Phone Server hosts such files for fully automated configuration of the device.
See:
Title | Description | Details | |||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Server Name * |
|
||||||||||||||||||||||||||||||||||||||||||||||||
Description * |
|
||||||||||||||||||||||||||||||||||||||||||||||||
Version * |
|
||||||||||||||||||||||||||||||||||||||||||||||||
Deployment Mode * |
|
||||||||||||||||||||||||||||||||||||||||||||||||
HCS CUCM |
|
||||||||||||||||||||||||||||||||||||||||||||||||
CUCM |
|
||||||||||||||||||||||||||||||||||||||||||||||||
Virtual Machine |
|
||||||||||||||||||||||||||||||||||||||||||||||||
NTP Server for phones * |
|
||||||||||||||||||||||||||||||||||||||||||||||||
Application Space |
|
||||||||||||||||||||||||||||||||||||||||||||||||
Backup Application Space |
|
||||||||||||||||||||||||||||||||||||||||||||||||
Credentials |
|
||||||||||||||||||||||||||||||||||||||||||||||||
Description |
|
||||||||||||||||||||||||||||||||||||||||||||||||
Type Credential * |
|
||||||||||||||||||||||||||||||||||||||||||||||||
User ID |
|
||||||||||||||||||||||||||||||||||||||||||||||||
Password |
|
||||||||||||||||||||||||||||||||||||||||||||||||
Network Addresses |
|
||||||||||||||||||||||||||||||||||||||||||||||||
Type Address Space * |
|
||||||||||||||||||||||||||||||||||||||||||||||||
Description |
|
||||||||||||||||||||||||||||||||||||||||||||||||
IP Addr V4 |
|
||||||||||||||||||||||||||||||||||||||||||||||||
Conn Parms |
|
||||||||||||||||||||||||||||||||||||||||||||||||
Name * | Name for this instance of generic driver connection details. |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Description * | Description for this instance of generic driver connection details. |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Version * | Version of models to use. |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Authentication Method * | Type of authentication to use when interfacing to the external service. |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Username | Username to use with specified authentication method. |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Password | Password to use with specified authentication method. |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Token | Token to use with specified authentication method. |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Test Connection URI | URI to use when testing connection to external service, e.g. https://service.domain/api/health, {{ driver_parameters.host_base }}/status |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Secure Driver Parameters | Additional secure parameters for the driver |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Name * | Name of additional secure driver parameter. |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Value * | Value of additional secure driver parameter. |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Driver Parameters | Additional parameters for the driver |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Name * | Name of additional driver parameter. |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Value * | Value of additional driver parameter. |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Default Request Headers | Default HTTP request headers to send with all device model API operation requests. Defaults specified here will be overriden by request headers specified on individual device model API operation definitions. |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Name * | Name of HTTP request header, e.g. Accept. |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Value * | Value of HTTP request header, e.g. text/plain. |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Default Response Handlers | Default handlers to execute on all API operation responses. Only those response handlers' which condition evaluates to True are executed. |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Condition * | Jinja template which if evaluation results in a value of True will cause the specified handler type to be executed, e.g. {{ status_code == 429 }}. |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Type * | Response handler type to execute if specified condition evaluates to True, e.g. Backoff & Retry. |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Session Based Auth Request | Describes the API request required to obtain a valid auth token. |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Login URI | URI for the initial Login request. This is a jinja template with custom functions and driver parameter context available. |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Login HTTP Method | HTTP method for initial login request. Default: POST |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Login Request Headers | Request headers for the initial login request. |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Header Name | Name of session request header, e.g. Cookie. |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Header Value | Value of session request header, e.g. session=12345. This is a jinja template with custom functions and driver parameter context available. |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Login Request Body Template (POST) | Request body for the initial login request if the method is POST. This is a jinja template with custom functions and driver parameter context available. |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Session Expire Time (min) | The amount of time a session is valid specified in minutes. |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Headers To Cache | Session headers to capture from the login response and include for requests after the initial login. |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Header Name | Name of session request header, e.g. Cookie. |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Header Value | Value of session request header, e.g. session=12345. This is a jinja template with custom functions and response body, header & cookie context available. |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Common Actions | Actions used identically by many device models |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Action * | Name of the device model operation for e.g. add |
|
|||||||||||||||||||||||||||||||||||||||||||||||
URI | URI for the API request |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Target | Target of this operation Default: HTTP |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Request Format | Request format Default: JSON |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Response Format | Response format Default: JSON |
|
|||||||||||||||||||||||||||||||||||||||||||||||
HTTP Method | HTTP method for API request Default: get |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Response Code Template | Jinja template for mapping API endpoint specific error/status response |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Request Headers | HTTP request headers to send with API operation request. Takes precedence over default request headers specified on related Connection Parameters Type instance. |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Name * | Name of HTTP request header, e.g. Accept. |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Value * | Value of HTTP request header, e.g. text/plain. |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Response Handlers | Handlers to execute on API responses. Only those response handlers' which condition evaluate to True are executed. |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Condition * | Jinja template which if evaluation results in a value of True will cause the specified handler type to be executed, e.g. {{ status_code == 429 }}. |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Type * | Response handler type to execute if specified condition evaluates to True, e.g. Backoff & Retry. |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Variables | List of context variables availble to template rendering (supports Macros) |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Name | Context variable name. This will appear in the context as 'variables.<name>' |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Value | Value of this variable. This field supports Macros |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Pre-request Calls | List of API calls to make before making this request |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Post-request Calls | List of API calls to make after making this request |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Request Template | Jinja template for API request. Maps system schema to external application schema. |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Response Template | Jinja template for API response. Maps external application schema to system schema. |
|