Course11:Basic - innovaphone overall Product Design
Jump to navigation
Jump to search
innovaphone products serve to implement IP telephony. To build up an IP telephony system, there are few types of products required:
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.
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.
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.
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.
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 is presented to one of the registered endpoints in a round robin fashion.
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.
As the PBX won't maintain any outgoing registrations itself, interfaces that themselves require a registration (such as SIP trunks) can be handled by the relay too. In this case, it will maintain 2 parallel VoIP registrations, one to the SIP provider and one to the PBX. The SIP provider registration is then treated just like any physical interface.
Apart from the ISDN, CAS, and FXS interfaces, the relay features a number of of virtual interfaces. Calls to these will be terminated locally in the relay.
Virtual interfaces will never originate calls.
Calls directed to these interfaces will play music on hold (TEST), dial-tones (TONE) or echo any incoming media (ECHO).
The HTTP interface (a.k.a webmedia) will connect any call and will retrieve the media stream played to the caller from a (possibly remote) web server. Custom music on hold or announced played in IVR type situations can thus be provided by customers on a web server (either an innovaphone gateway with CF card or a standard web server such as IIS or Apache).
Some of the gateways feature a conferencing engine that provides mixing capabilities for a number of calls (currently up to 60, depending on the gateway used).
All gateways feature a fax interfaces. It works similar to the Webmedia interface, it retrieves/stores a file via HTTP and converts it to a T.38 fax call.
innovaphone devices can work as DHCP clients. Apart from requesting an IP lease from the server, a number of standard and vendor specific options are understood. This allows for a very convenient way of specifying site specific configuration options, especially to telephones. Those would be specified as DHCP (vendor) options in the local DHCP servers configuration.
It is often difficult or impossible to use an existing DHCP server to provide vendor options. Also, in some installations there is no DHCP server available at all.
To help with such situations, innovaphone devices also support DHCP server mode. In this mode, the device operates as a standard DHCP server and will issue leases and DHCP options. This is usually much easier to configure.
In order not to interfere with an existing DHCP server, the innovaphone server can be configured to support only innovaphone devices. This allows an innovaphone DHCP server to coexist with an existing DHCP server infrastructure.
There are also other versions of this article available:
Course11 (this version) | Course10 | Course12
This book describes the overall design that is shared by all innovaphone devices.
What innovaphone products are all about
innovaphone products serve to implement IP telephony. To build up an IP telephony system, there are few types of products required: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.
phones and 
, using WLAN technologies to carry the IP data stream 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.
is required that converts the IP data stream back to pure voice and sends it via the DECT protocol to the 
. 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 old-style digital (a.k.a. ISDN) or even analogue (a.k.a POTS) 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 analogue, ISDN and DECT. An obvious example for the use of a gateway is the connection to the PSTN. A slightly less obvious scenario is the integration of a traditional fax device.
. 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 analogue, ISDN and DECT. An 
for the use of a gateway is the connection to the PSTN. A slightly less obvious scenario is the 
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).
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.
A special instance of a call server is ''the Gatekeeper''. Although technically, the PBX is a gatekeeper too, the term refers to a separate gatekeeper that can be enabled on innovaphone gateways. It is especially tailored to meet the call processing requirements found in legacy PBX trunking scenarios. Please note that although this is a term that stems from H.323, all innovaphone devices support both SIP and H.323 simultaneously.
Appliances
All innovaphone gateways are designed as appliances. That is, they come with their own dedicated, robust high-performance hardware. The PBX uses a gateway as its platform, so it runs on an appliance too. As a result, the complete core telephony system is appliance-based. No need for PC hardware. No need for 3rd party operating systems. innovaphone appliances feature their own, proprietary, dedicated, well engineered real-time message passing operating system. Furthermore, there are no rotating parts in it. No hard disks, no fans. This is how innovaphone ensures the core telephony components five nines availability.
Starting with v9 innovaphone offers its PBX as Innovaphone Virtual Appliance (IPVA), a virtual machine to be run on a virtualization platform. Currently, 
VMware is is the solely supported virtualization platform.
The IPVA is a software-only solution. It appears as and performs like an innovaphone "hard-box". However, there is obviously no physical interface (except for Ethernet) available in the IPVA. If e.g. DSP resources or ISDN interfaces are needed, an appropriate gateway or adapter must be added.
Starting with v9 innovaphone offers its PBX as
VMware is is the solely supported virtualization platform.The IPVA is a software-only solution. It appears as and performs like an innovaphone "hard-box". However, there is obviously no physical interface (except for Ethernet) available in the IPVA. If e.g. DSP resources or ISDN interfaces are needed, an appropriate gateway or adapter must be added.
Software Building Blocks
Although different innovaphone products have different purposes, it turns out that they have many functions and features in common. So whenever functions are the same, the software used to implement them are the same too and thus the user interface to manage them is shared across products. In fact, once you are familiar with one innovaphone product, you will feel comfortable with just any innovaphone product.
So lets look at the various building blocks more closely.
So lets look at the various building blocks more closely.
Admin User Interface
The administrative access to the devices is simply through your favourite web browser. Whether you're dealing with an ISDN gateway, a telephone or a DECT gateway does not change things really. Some devices will have more entries in the menu, some less. This may be due to different functionality (an ISDN gateway will have no DECT section as the DECT gateway has).
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.
ISDN gateway, a 
, a telephone or a 
or a DECT gateway does not change things really. Some devices will have more entries in the menu, some less. This may be due to different functionality (an ISDN gateway will have no DECT section as the DECT gateway has). 
does not change things really. Some devices will have more entries in the menu, some less. This may be due to different functionality (an 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. 
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 
may be defined and fine grained access levels assigned to individual administrators. 
assigned to individual administrators. Web Server
To implement the browser based administration user interface, each innovaphone device obviously features a built in web service to deliver the user interface files. However, this web server can do a lot more.
Access is provided for various applications, such as CF file storage through WebDAV or 3rd party call control web services through SOAP.
webapps
All benefit from encryption via TLS (i.e. HTTPS), secure digest authentication and fine grained access control.
Access is provided for various applications, such as CF file storage through WebDAV or 3rd party call control web services through SOAP.
All benefit from encryption via TLS (i.e. HTTPS), secure digest authentication and fine grained access control.
Web Client
innovaphone devices also have an HTTP or web client built in. It allows the device to communicate with standard web server implementations or with other innovaphone devices.
Consider a voicemail on a PBX. The HTTP client gives you the free choice to store voicemails on the PBX's local CF card, another innovaphone device with CF card or on external web servers such as IIS or apache. The web client is used to:
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.
Consider a voicemail on a PBX. The HTTP client gives you the free choice to store voicemails on the PBX's local CF card, another innovaphone device with CF 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 
itself. However, in a more complicated scenario, the web server used may be a different box or a 
or a 3rd party web server. This provides for a high flexibility in designing solutions.
. This provides for a high flexibility in designing solutions.Router
All (!) innovaphone devices provide IP routing and VPN capabilities.
Most of the gateways with ISDN interfaces provide the ability to dial-in to the box via ISDN. While nowadays people don't build up private networks using ISDN any more, this comes in handy when it comes to remote maintenance. It allows a service engineer to dial-in to the box and then - depending on the configuration - access the box itself or the complete network behind it.
All innovaphone devices with Ethernet interface support PPP connections over Ethernet. This allows you to establish a connection to your IP provider, e.g. in a SOHO scenario.
All innovaphone devices with Ethernet interface support PPP connections over IP, a.k.a. PPTP. This allows to establish (encrypted) VPN connections over the public internet. Stacking a PPTP on top of a PPPoE connection provides for a full corporate network integration without the need for any extra equipment.
This can be done merely to connect a single home office phone or to connect a full remote small office network.
innovaphone devices can even be used to terminate incoming PPTP connections, although you would usually employ a dedicated network device for this task.
innovaphone devices can be used to perform NAT towards the internet. This does not only include standard protocols such as HTTP, FTP, SMTP, IMAP etc. but also PPTP or even H.323.
PPP over ISDN
Most of the gateways with ISDN interfaces provide the ability to dial-in to the box via ISDN. While nowadays people don't build up private networks using ISDN any more, this comes in handy when it comes to remote maintenance. It allows a service engineer to
dial-in to the box and then - depending on the configuration - access the box itself or the complete network behind it.
and then - depending on the configuration - access the box itself or the complete network behind it.PPP over DSL (PPPoE)
All innovaphone devices with Ethernet interface support PPP connections over Ethernet. This allows you to establish a connection to your IP provider, e.g. in a SOHO scenario.
PPP over IP (PPTP)
All innovaphone devices with Ethernet interface support PPP connections over IP, a.k.a. PPTP. This allows to establish (encrypted) VPN connections over the public internet. Stacking a PPTP on top of a PPPoE connection provides for a full
corporate network integration without the need for any extra equipment.
without the need for any extra equipment.This can be done merely to connect a single home office phone or to connect a full remote small office network.
innovaphone devices can even be used to terminate incoming PPTP connections, although you would usually employ a dedicated network device for this task.
NAT
innovaphone devices can be used to perform NAT towards the internet. This does not only include standard protocols such as HTTP, FTP, SMTP, IMAP etc. but also PPTP or even H.323.
PBX
The PBX software component is the heart of an innovaphone solution.
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.
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.
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 
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 is presented to one of the registered endpoints in a round robin fashion.
.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
The PBX does support VoIP clients only, any non-VoIP equipment must be connected using appropriate gateways. However, the kind of VoIP protocol to use, either H.323 or SIP, doesn't matter.
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.
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.
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.
Relay
The Relay is the software component on innovaphone devices that handles physical voice interfaces (such as ISDN basic rate, primary rate or analogue FXS). It manages the interface in terms of status and physical configuration and provides the necessary protocols (such as ISDN, QSIG, CAS) to implement both signalling and media channel.
To interface to the VoIP world and in particular to provide access to its interfaces for VoIP endpoints registered to the PBX, the relay will maintain individual registrations to the PBX for each interface. This way, the interfaces are seen as standard VoIP endpoints from the PBX.
For calls from the PBX to the interfaces and vice versa, the call signalling protocols are translated and the media data is converted as required.
In many cases, calls from interfaces to on-behalf registrations are straight back and forth without any manipulation. However, in certain scenarios, call routing can be more sophisticated.
The relay's routing table provides a very powerful mechanism to configure the call routing depending on the called and calling party numbers, as well as the interfaces involved. Many call properties, such as calling and called party numbers can be manipulated as well. Call alternatives can be implemented, for example to fall back to an emergency trunk line when your standard trunk line is not available.
To interface to the VoIP world and in particular to provide access to its interfaces for VoIP endpoints registered to the PBX, the relay will
maintain individual registrations to the PBX for each interface. This way, the interfaces are seen as standard VoIP endpoints from the PBX. 
for each interface. This way, the interfaces are seen as standard VoIP endpoints from the PBX. For calls from the PBX to the interfaces and vice versa, the call signalling protocols are translated and the media data is converted as required.
Routing Table
In many cases, calls from interfaces to on-behalf registrations are straight back and forth without any manipulation. However, in certain scenarios, call routing can be more sophisticated.
The relay's
routing table provides a very powerful mechanism to configure the call routing depending on the called and calling party numbers, as well as the interfaces involved. Many call properties, such as calling and called party numbers can be manipulated as well. Call alternatives can be implemented, for example to fall back to an emergency trunk line when your standard trunk line is not available. Special Interfaces
SIP Trunks
As the PBX won't maintain any outgoing registrations itself, interfaces that themselves require a registration (such as SIP trunks) can be handled by the relay too. In this case, it will maintain
2 parallel VoIP registrations, one to the 
, one to the SIP provider and one to the PBX. The SIP provider registration is then treated just like any physical interface.Virtual Interfaces
Apart from the ISDN, CAS, and FXS interfaces, the relay features a number of of
virtual interfaces. Calls to these will be terminated locally in the relay. Virtual interfaces will never originate calls.
TEST, ECHO, TONE
Calls directed to these interfaces will play music on hold (TEST), dial-tones (TONE) or echo any incoming media (ECHO).
Webmedia
The HTTP interface (a.k.a webmedia) will connect any call and will
retrieve the media stream played to the caller from a (possibly remote) web server. Custom music on hold or announced played in IVR type situations can thus be provided by customers on a web server (either an innovaphone gateway with CF card or a standard web server such as IIS or Apache). 
played to the caller from a (possibly remote) web server. Custom music on hold or announced played in IVR type situations can thus be provided by customers on a web server (either an innovaphone gateway with CF card or a standard web server such as IIS or Apache). Conferencing Engine
Some of the gateways feature a
conferencing engine that provides mixing capabilities for a number of calls (currently up to 60, depending on the gateway used). Fax
All gateways feature a
fax interfaces. It works similar to the Webmedia interface, it retrieves/stores a file via HTTP and converts it to a T.38 fax call. Looped-in Mode
Some gateways are especially designed to be looped-in to an ISDN trunk line. Consider a migration scenario where an existing legacy PBX is to be replaced by an innovaphone PBX. It is often not desired to remove the legacy PBX ad-hoc. Instead, new users shall be provided with IP phones connected to the IP PBX, whereas existing users keep their extension on the legacy PBX and are moved to the new PBX over time.
In this scenario, any investment in the legacy PBX, either in terms of hardware (interface cards) or service (configuration) is clearly not desirable. The innovaphone solution (often referred to as soft migration) is to loop-in an innovaphone gateway into the existing legacy PBX's trunk line(s).
The IP810 and IP6010 (as well as some of the discontinued gateways) feature a looped-in mode especially for this scenario:
In this scenario, any investment in the legacy PBX, either in terms of hardware (interface cards) or service (configuration) is clearly not desirable. The innovaphone solution (often referred to as soft migration) is to
loop-in an innovaphone gateway into the existing legacy PBX's trunk line(s). 
an innovaphone gateway into the existing legacy PBX's trunk line(s). The IP810 and IP6010 (as well as some of the discontinued gateways) feature a looped-in mode especially for this scenario:
- Calls from ISDN to ISDN (e.g. from the PSTN to a legacy extension) will be directly switched between the 2 interfaces. This ensures that there are no VoIP resources are used (e.g. DSP channels) and no extra voice delay is added
- When the gateway is switched off, or fails to boot up for any reason, the corresponding interfaces are connected transparently, so that access to the trunk line(s) from the legacy PBX is still possible
DHCP
Client
innovaphone devices can work as DHCP clients. Apart from requesting an IP lease from the server, a number of
standard and vendor specific options are understood. This allows for a very convenient way of specifying site specific configuration options, especially to telephones. Those would be specified as DHCP (vendor) options in the local DHCP servers configuration.Server
It is often difficult or impossible to use an existing DHCP server to provide vendor options. Also, in some installations there is no DHCP server available at all.
To help with such situations, innovaphone devices also support DHCP server mode. In this mode, the device operates as a standard DHCP server and will issue leases and
DHCP options. This is usually much easier to configure. In order not to interfere with an existing DHCP server, the innovaphone server can be configured to
support only innovaphone devices. This allows an innovaphone DHCP server to coexist with an existing DHCP server infrastructure.