Course13:IT Advanced - 02 innovaphone overall Product Design: Difference between revisions
m (Protected "Course13:IT Advanced - 02 innovaphone overall Product Design" ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite))) |
|||
(One intermediate revision by one other user not shown) | |||
Line 1: | Line 1: | ||
{{#moodlebook: Master Templates / V13 Templates / Advanced | innovaphone overall Product Design | | {{#moodlebook: Master Templates / V13 Templates / Advanced | innovaphone overall Product Design | 133 }} |
Latest revision as of 11:37, 12 October 2023
This book describes the overall design that is shared by all innovaphone devices.
What innovaphone products are all about
IP Phone
IP Phones are just like traditional telephone sets. They interface to the end user and let them talk to each other. They take the voice, convert it to an IP data stream and send it to the destination, where the voice stream is recreated from the data received.
Like you would expect, there are fixed line phones and wireless phones, using WLAN technologies to carry the IP data stream over the air.
And as before, wireless phones can use DECT over the air. However, as DECT was designed to carry voice only and cannot practically carry IP data, a gateway is required that converts the IP data stream back to pure voice and sends it via the DECT protocol to the DECT handset.
innovaphone offers a pretty wide range of fixed line and wireless phones.
Gateway
Unfortunately, not all telephones you will want to call are IP phones . Some of them are actually analog (a.k.a POTS) or even old-style digital (a.k.a. ISDN) ones. To be able to call those, you will need a gateway. In general, a gateways role is to convert the IP data stream carrying your voice and your signalling data to a physical media of certain type and vice versa. Commonly used media are analog, ISDN and DECT. An obvious example for the use of a gateway is the connection to the old-style digital PSTN. A slightly less obvious scenario is the integration of a traditional fax device.
In innovaphone speak, a gateway can host a PBX (see below). Devices that are gateways technically, but cannot host a PBX are either called adapter (if they connect to terminal equipment) or media-gateway (if they connect to things like a trunk line).
Gateways can also host conferencing resources. These allow for multi-party voice, video and application-sharing conferences.
SBC
A special case of a gateway is an SBC. An SBC is used to connect to an IP based (usually SIP) trunk provider (a.k.a. SIP provider). Although an SBC does not connect to a different physical medium, it provides a controlled interface between your PBX system and the SIP provider's network. In the innovaphone system, an SBC behaves much like a gateway interface and is thus found where the other interfaces (TEL->analog, BRI/PRI->ISDN) are located too.
Call Server
When an IP phone tries to place a call, someone needs to determine the other end to call. If the called party (which may be identified by a number as in the PSTN or by a name) is an IP phone in the same system, its IP address needs to be determined and the call forwarded to the destination. If it is an external call destination (e.g. a PSTN subscriber), a proper gateway must be identified and the call forwarded accordingly. For the call server to be able to manage the calls, all IP phones and gateways must be made known to it, a process called registration.
With innovaphone, the call server is known as the PBX. Although this is a product which you can (and actually need to ) buy separately, it is not a device. Instead, it is a software that is present on the gateways and is enabled by adding a proper license.
myApps
myApps is innovaphone's UC client which runs on Windows, Android, iOS and MacOS). However, it's much more than a UC client: it is an App ecosystem which allows the user to run arbitrary Apps provided by innovaphone or 3rd Party vendors. myApps comes with out-of-the-box Apps with which end users can chat, make phone calls, share their screen contents, make video conferences, fax, operate and listen to their voicemails and check the Presence status of their colleagues calendars. Even more, Apps for administrators help to install, configurate and monitor the whole system.
myApps can run in any contemporary browser or - with some additional features - as native application.
App Platform
The App Platform is an additional component that provides various services (known as App Services). App Services in turn provide user interfaces (known as Apps) that allow both administrators and end users to use the services. An example for an App Service would be a contact database that provides contact information to telephony endpoints so that users can dial from a directory and incoming calls are resolved to the names of the callers. Like with the PBX, the App Platform is not a device. Instead, it is a software that is present on the gateways and runs on a separate processor so that it can work in parallel to the PBX even if it runs on the same gateway platform.
Virtual Appliances
IPVA
App Platform
Software Building Blocks
So let's look at the various building blocks more closely.
Advanced Admin User Interface
Most of the user interface pages use XSL instead of plain HTML. So they are XML pages with accompanying XSLT and CSS files that control the design presented to the user.
This approach allows us to implement OEM versions of the user interface just by providing appropriate XSLT/CSS files. But apart from that, it allows 3rd party software integrators to access any information presented by the user interface by just retrieving and parsing the raw, clean XML data structures.
Multiple administrative accounts may be defined and fine grained access levels assigned to individual administrators.
Web Server
Web Client
Consider a voicemail on a PBX. The HTTP client gives you the free choice to store voicemails on the PBX's local SSD card, another innovaphone device with SSD card or on external web servers such as IIS or Apache. The web client is used to:
- retrieve audio (music on hold, announcements) files
- store audio for call recording
- retrieve voice xml scripts including external web application integration and remote file storage/retrieval
- firmware mass deployment
- configuration deployment (provisioning)
- automated configuration backups (incl. personal user directories)
- sending call detail records to external billing applications
- system log, event and alarm message concentration
- and more
It is a fundamental design principle for innovaphone devices to always implement access to resources using standard protocol interfaces. For example, when a voicemail records a call, it will open a WebDAV session to a web server and store the audio in a file. In a simple installation, the web server used will be the box running the PBX itself. However, in a more complicated scenario, the web server used may be a different box or a 3rd party web server. This provides for a high flexibility in designing solutions.
Router
PPP over DSL (PPPoE)
PPP over IP (PPTP)
PPP over RTP (RTPTP)
NAT
PBX
Registrations
Registration
As said before, the PBX component provides for the management of all VoIP endpoints (that is, phones, gateways and adapters). For this to work, all VoIP endpoints need to register with the PBX. Once endpoints are registered, calls can be placed between them.
It is important to understand that the PBX only knows about VoIP endpoints! Non-VoIP entities such as analog phones, PSTN trunk lines etc. are not known to the PBX. Instead, the respective gateways and adapters stand in and register on behalf of such entities.
Even if the non-VoIP entity (e.g. a trunk line) is handled by the same device that is also running the PBX (as all gateway platforms have the ability to run a PBX), the PBX itself will only know about a stand-in registration of the local gateway for that trunk line.
Objects
PBX Objects
The PBX maintains a number of objects of different types to implement the call processing requirements. The most obvious of these object types is the User object. It represents an extension of the PBX. When a VoIP endpoint (e.g. an IP phone) registers with the PBX, it can supply the name of an user object (and possibly some credentials). When registration is successful, calls to the users extension will be forwarded to the registered phone.
Likewise, when the VoIP endpoint initiates a call, the PBX will forward the call to the destination using the user objects properties (e.g. it will send the users extension number as calling line ID).
There are a number of common object properties, such as Name and Number (extension), which are shared by all objects. Others are specific to the respective object type.
Registration Objects
Some of the PBX objects (such as the aforementioned User object) require a VoIP endpoint to register with. With no endpoint registered, they do little or nothing. There main purpose is to pass calls to and from endpoints registered with this object.
These object types mainly differ by the call handling strategies. For example, the Executive object will refuse to pass calls destined to the executives extension to the executives phone (as the User object would do). Instead, the call is sent to a secretary.
Generally, for registration objects, calls destined to the object are passed to VoIP endpoints registered on that object.
To place a call through the PBX, any VoIP endpoint must be registered.
Multiple Registrations
Generally, when a single VoIP endpoint can register with a PBX object, multiple endpoints can do too. Depending on the object type, call handling may differ then.
If for example, multiple endpoints register with a User object, all calls placed by those endpoints are performed equally (e.g. the same calling line id is used). Calls destined to the User object's extension, will be forked, so that each registered endpoint will receive a call setup.
In contrast to that, when calls are placed to a Trunk object (which implements access to a trunk line bundle), each call may be presented to one of the registered endpoints in a round robin fashion (see
Self-containing Objects
However, there are other objects which fully or partly implement endpoints for a call. These objects do not necessarily require a registered endpoint to function.
For example, the Voicemail object does not require any registration (in fact, you must not register with a voice mail object!). Instead, any call destined to the voice mail objects extension is terminated within the PBX the object is configured on itself. It can be useful to consider this when networked PBXs are designed.
Protocols
During registration, each VoIP endpoint informs the PBX of the VoIP protocol it intends to use. Even multiple registrations on the same PBX object can be done using different protocols at the same time. This allows users for example, to register with H.323 and SIP phones simultaneously.
Interworking
When a SIP-endpoint calls an H.323 endpoint or vice versa, the PBX will translate the two signaling protocols used. Both endpoints are unaware of the protocol the other end is using.