Howto:Hosting with V10

From innovaphone wiki
Jump to navigation Jump to search

This document describes general recommendations for setting up a „hosted PBX“-environment. It is based on a reference implementation done early 2013. Everything said in this article is merely a recommendation and you may deviate from it for real-life projects. However, it may still serve as a guideline of “what to think of”.

There are no specific configurations given throughout the article. As such, it targets an iCE with some decent knowledge about innovaphone products as an audience.

This article is still “work in progress”.

Overview

Each customer receives a dedicated PBX (best run as IPVA). So no “dynamic PBX”s are used. Each customer has exactly one such PBX. So no Slave- (as they do not seem to make sense) and no Standby-PBX (as this is better implemented using VMware tools such as High Availability or Fault Tolerance). This article does explicitly not deal with mixed environments where some PBXs are hosted and some on-premise.

Further services (apart from the basic PBX) such as e.g. fax are provided by multi-tenant capable applications. How many customers and/or users (i.e. extensions) can be served by a single such application is for further study. However, from an administration point-of-view, it seems to be easier calculating the same application-server to number-of-customers ratio for all the applications, as it allows organizing the whole setups in clusters where a specific set of customers is associated to a specific set of application servers.

In a real-life setup, there may or probably will be a central management server which may run software to simplify the management of the whole setup as well as provide an end customer portal. This server, called ‘’Management Server‘‘ in the overview graph is thought to be specific to the PBX hosting provider and is thus – although it has an important impact – not discussed in this document.

Cloudkom-grobuebersicht1.png

Most of the hosted services, as well the customer-PBXs and the shared services, will be located in a private network run by the hosting provider. This is to make sure they cannot be easily attacked and also to save on publicly available IP addresses (which may be a scarce resource). As a result, from a TCP/IP point-of-view, these services are not reachable from the customers own private network. Also, to save on resources and reduce complexity, no VPN is set up between the customer and the hosting provider. To implement the required customer access to these services, there are 2 extra services which need to have an additional external IP address (“dual homed”). These are called “SBC” and “Media-PBX”.

The SBC provides:

  • Proxy registration of customers terminal devices (e.g. phones) located on premise to the customer PBX
Terminals in fact register with the SBC which in turn entertains a proxy-registration to the customer PBX for each endpoint
  • inbound NAT with port maps for selected protocols (such as e.g. HTTPS/443 und LDAPS/636,714)

The Media-PBX

  • provides a reachable media endpoint for media data provided or consumed by services within the hosting providers private newtork
This includes e.g. music on hold, locally generated calling tones, Voicemail, multi-party conferences and fax

This architecture ensures that the hosting providers network topology is invisible to 3rd parties (including possible attackers). Furthermore, the hosting provider only needs 2*n+1 public IP Addresses (where n is the number of shared service groups).

Cloudkom-netzuebersicht1.png


Passwords

Throughout the system, a number of passwords are used in various places. It is critical to use as less passwords as possible to make day-to-day administration easy and as much passwords as necessary to keep things secure. So here is an overview:

  • Admin passwords
Admin user authentication is based on Keberos. Each admin thus can and should have individual accounts and passwords (referred to as individual admin password)
all devices shall have a "local admin" passsword which should be kept secret and not be known by normal administrators and should normally never be used. This is referred to as system-wide admin password)
  • PBX passwords
PBX passwords needs to be the same in all oft the hosting providers PBXs (and do not need to be typed-in anywhere except during a PBXs initial configuration) . The are referred to as PBX password
  • Object password. There are 2 kinds:
    • Passwords, which need to be known to the customer. Registration passwords for terminal devices would be an example. Those are referred to as customer registration password). Another example are initial passwords for myPBX (that is, user passwords). They are referred to as customer login password. For each customer (not for each line), a distinct customer registration password is defined, which normally never changes. Furthermore, another customer login password is generated, which is used initially for all user objects but will be changed by the end users.
    • Password which are not disclosed to the customer. These are used for internal registrations, e.g. a local interface or gateway registering at the customer PBX. For this, the pbx password will always be used
  • Kerberos DB password
The PBX password shall be used for encryption of the Kerberos database (as it does make no sense to use a different password her)

Unfortunately, the Linux AP has no support for Kerberos so separate admin password are required. We distinguish passwords used during daily administration and those which are not.

  • Linux Admin password
this is the password used in day-to-day administration, referred to as Linux Admin password. It is used as web server credentials, webdav access credentials, application access credentials, 'innovaphone Reporting access credentials, innovaphone Fax access credentials etc.
  • Linux System password
the password that is used as root credentials. Fort this, the PBX password shall be used
The database passwords (e.g. postgresql admin password) can be left as by default, as the DB server is accessible from 127.0.0.1 only anyway

Customer-ID

Each customer should have a unqiue customer id. It should be “safe” (that is, no umlaut, no spaces, no obscure special characters). Something like e.g. Kuenkel0001 will do.

NTP

All devices require correct time setting. They all must have be a working NTP time source configured (and probably also a working alternate).

The dual-homed devices (see above) shall use 2 reliable time sources (either run by the hosting provider or from the internet). All other devices shall use "their" own SBC as NTP Server (a backup time source is not strictly required here as these devices are anyway unusable for customers when the SBC is down).

Certificates

The entire HTTP and LDAP traffic from and to the customers network is encrypted. This affects for example a customers access to the PBX (e.g. if the customer is granted (limited) access to the PBX config or for myPBX), as well as access to the reporting service.

To facilitate access to these devices without any warnings issued by the clients (e.g. browser security alerts) all devices require suitable certificates (that is, the host name and IP address must be noted in the certificate and they must be derived from a single signing authority so that end-users only need to import a single root certificate in order to accept all of these device certificates.

The devices built-in certifcates cannot be used as they only refer to the devices NetBIOS name (e.g. IPVA-a8-5a-38) which will not be used to access the devices. Also, in the case of IPVA, the default certificate is self-signed as opposed to being derived from the aforementioned uniform root certificate.

To derive device-certificates which all inherit from the same root certificate, a so-called RootCA is needed.

There are multiple ways to implement this. Although there are better schemes available, one way to do it that requires no 3rd party gear is to generate a RootCA (in General/Certificates/RootCA) on a dedicated IPVA. This RootCA then can be used to generate all of the other certificates. They are stored in the IPVA’s virtual CF card (/DRIVE/CF0/CA/certs/) and can be exported to the other devices from there.

RootCA

For the RootCA, we use the IPVA that also implements the central Kerberos server. Unfortunately, the current firmware that each generated device certificate will also replace the IPVA’s own device certificate. This is of course somewhat unfortunate, however, it is not really an issue as no end-customer will ever access the Kerberos IPVA anyway. The Kerberos server itself does not rely on the device certificate.

You first generate a RootCA on the RootCA-IPVA ('General/Kerberos). The following data must be used:

C=your-country (e.g. Germany) , O=hoster, CN=hoster Device Certification Authority, Key-length 4096, lifetime 20 years

This new RootCA (which is now the IPVA’s device certificate) needs to be trusted on the IPVA (General/Admin).

Device Certificates

To create individual device certificates, use the RootCA created and use the following data:

Key 4096, Common Name=devices NetBIOS Name, Organization=hoster, Country=your-country (e.g. Germany) , DNS Name 1=devices external IP address, DNS Name 2=devices internal IP address, IP Address 1=devices external IP address , IP Address 2=devices internal IP address

For devices with an internal IP address only, it is important to specify the IP address of NAT router used to access the device as external IP address (e.g. for a customer PBX, this will be the SBC used). You specify the IP address only, not the port map.

If you intend to assign real DNS names to your devices, you may of course specify these as DNS Name 3 too.

In order to be able to export the new certificate to the target device, you need to make sure you tick the Backup on CF check-mark, so it is saved on the CF as serialno.pem. To transfer the new certificate to the target device, take note of the serial number and download the respective certificate file from /DRIVE/CF0/CA/certs/serialno.pem. This file can then be uploaded to the target device (General / Certificates / Device certificate / Upload).

Browser Installation of the Root Certificate

To get rid of the browser security alerts when accessing devices with e.g. HTTPS, the public key of the root certificate must be trusted by the browser. For this, it needs to be exported in to a file (you can best do this from the RootCA’s trust list in General/Certificates/Download/PEM into certificate.crt).

It must then be imported to the browser. This needs to be done once by both administrators and customers.

Firefox

  • Extras / Einstellungen / Erweitert / Zertifikate anzeigen / Zertifizierungsstellen / Importieren
  • import the .crt file
  • tick Dieser CA vertrauen, um Websites zu identifizieren

Internet Explorer

  • Extras / Internetoptionen / Inhalte / Zertifikate / Beabsichtigter Zweck Clientauthentifizierung / Vertrauenswürdige Stammzertifizierungsstellen / Importieren
  • import the .crt file

Kerberos

Kerberos is used to implement authentication for all devices. This includes both devices in the PBX hosting provider’s infrastructure and the CPE. For this to work, all devices must subscribe to the Kerberos realm. The PBX hosting provider’s DNS domain (e.g. ‘’hoster’’.tld) should be used as Kerberos domain name. This way, Kerberos can be found using DNS SRV records.

The IPVA used as RootCA can be used as master kerberos service too. A stand-alone Kerberos server (that is, the one that is implemented in the Gateway level) is being used. The (probably limited) number of admin accounts is maintained manually.

In fact, if the PBX hosting provider uses an active directory service to manage employee accounts, an AD-replicated PBX run on the central Kerberos IPVA is also a viable option.

Either way, a standby Kerberos server should be setup as a separate IPVA and can be replicated from the master kerberos as usual.

Unless an active directory is used, no trust relationships are required. If so, the system-wide admin password should be used as shared secret.

The devices which rely on kerberos for authentication (that is, all devices!) locate the Kerberos servers using DNS SRV records. Devices within the hosting provider’s private network use the internal IP address for this; external (e.g. CPE) devices use their respective SBC. For this to work, each SBC needs an UDP NAT map (udp/7088 -> kerberos-intern-ip:88 and udp/7089 -> secondary-kerberos-intern-ip:88). The PBX hosting provider’s DNS needs to have the following entries: 

# hoster.tld is the hosters domain used as kerberos realm name
A kerberos1i.hoster.tld x.x.x.x (interne Adresse des primären Kerberos)
A kerberos2i.hoster.tld y.y.y.y (interne Adresse des sekundären Kerberos)
A sbc1.hoster.tld x.x.x.x (externe Adresse des SBC1)
A sbcn.hoster.tld x.x.x.x (externe Adresse des SBCn, n ist Sequenznummer des SBC)

SRV _kerberos._udp.hoster.tld
    priority       = 0
    weight         = 0
    port           = 88
    svr hostname   = kerberos1i.hoster.tld

SRV _kerberos._udp.hoster.tld
    priority       = 5
    weight         = 0
    port           = 88
    svr hostname   = kerberos2i.hoster.tld

SRV _kerberos._udp.hoster.tld
    priority       = 10
    weight         = 0
    port           = 7088
    svr hostname   = sbc1.hoster.tld

SRV _kerberos._udp.hoster.tld
    priority       = 15
    weight         = 0
    port           = 7089
    svr hostname   = sbc1.hoster.tld

SRV _kerberos._udp.hoster.tld
    priority       = 10
    weight         = 0
    port           = 7088
    svr hostname   = sbcn.hoster.tld

SRV _kerberos._udp.hoster.tld
    priority       = 15
    weight         = 0
    port           = 7089
    svr hostname   = sbcn.hoster.tld

With this setup, all devices will prefer the internal IP addresses. External (e.g. CPE) devices will of course not be able to reach these internal addresses, but they will succeed with one of the SBCs. Thus CPE devices will use any of the available SBCs, not necessarily their own. This will work as all SBCs ultimately NAT to the same Kerberos server.

Instead of relying on the PNX hosting provider’s DNS server, the SRV records can be set in the devices during staging. This way, the setup can be somewhat simpler as each device can be configured to use its associated SBC only: 

config change DNS0 
   /srv-name _kerberos._udp.hoster.tld/srv-target kerberos1i.hoster.tld /srv-port 88 /srv-prio 0 /srv-weight 0 
   /srv-name _kerberos._udp.hoster.tld /srv-target kerberos2i.hoster.tld /srv-port 88 /srv-prio 5 /srv-weight 0
   /srv-name _kerberos._udp.hoster.tld /srv-target sbcn.hoster.tld /srv-port 7088 /srv-prio 10 /srv-weight 0 
   /srv-name _kerberos._udp.hoster.tld /srv-target sbcndup.hoster.tld /srv-port 7089 /srv-prio 15 /srv-weight 0
   /a-name kerberos1i.hoster.tld /a-addr i.i.i.i
   /a-name kerberos2i.hoster.tld /a-addr i.i.i.i
   /a-name sbcn.hoster.tld /a-addr x.x.x.x
   /a-name sbcndup.hoster.tld /a-addr x.x.x.x

NB: the somewhat strange confuiguration of sbcndup.hoster.tld (which is in fact identical to sbcn.hoster.tld) is due to the fact that V10 firmware before beta6 did not support multiple SRV records for the same host.

Kerberos User

In addition to the accounts for the administrators, there must be a service account paccess used for programmatic access to the devices. This will for example be used by the Metadir server to access the SBC (and can also be used by a hosting provider specific administration software). In addition to that, this account is to be configured under Services/HTTP/Client for URLs https:// and http:// on the SBC, Media-PBX and customer PBXs. This allows all these device to access all other devices using HTTP/S.

The credential for this account need tob e kept securely, as they allow admin access to all devices in the infrastructure!

To facilitate automatic join into the kerberos domain during staging, there needs to be an additional special account with Join Realm rights only: : joiner, joiner. This account is not particularly relevant from a security point of view, as aside from adding or removing devices from a realm nothing relevant can be done on behalf of it.

Licenses

It is in the PBX hosting provider’s best interest to implement a centralized license management. A central licensing server instance is needed thus. This can be run on the master and standby Kerberos server. All licenses purchased by the PBX hosting provider are installed here. The license server runs a PBX. The only task for this PBX is to host the licenses and distribute them to the SBC and Media PBXs, which are registered as License only slaves and will further distribute the licenses to the customer PBXs (which are in turn registered as License only slaves to their respective Media-PBX).

If you choose to use a PBX based Kerberos server (see above), this same PBXs can be used.

The license server PBXs will have the PBX hosting provider’s domain name as System Name (e.g. hoster.tld) and . as PBX Name.

SBC

The SBC

  • accepts external registrations from customer CPE
  • provides a central (virtual) CF-card storage for non-sensitive data (e.g. firmware files)
  • supports mutliple customer PBXs. The exact number is yet ffs., however, we estimate no more than 135 currently. SBCs will simply be numbered (sbc1, sbc2 etc.)

NAT

  • The SBC will provide inbound NAT mappings for HTTPS and LDAPS. This allows for controlled access to the IPVAs within the PBX hosting provider’s private network from external. Each customer PBX uses its associated SBC for NAT, that is, each SBC provides NAT for all customers that have it associated as SBC. The number of customers per SBC is limited by the number of NAT maps that can be created, which in turn depends on the length oft he resulting config file line. Currently, there is a limit of approximately 290 maps per SBC. 2 distinctive maps are needed per customer
  • Additionally, some maps shared by all customers (e.g. for services like Metadir, FaxServer, Reporting) are required. About 20 maps should be reserved for this
  • So we end up with the aforementioned number of 135 customers per SBC

PBX

  • System Name is the PBX hosting provider’s domain name (e.g. hoster.tld)
  • PBX Name is sbcn
  • registers as Slave PBX with the central license server PBX (License Only)
  • receives required licenses from the central license server thus
Customer related Configuration
  • One Session Border object (SBC) for each (potential) terminal registration to a customer PBX
  • Long Name as well as Registration to internal PBX/Name set tot he CPE-ID (see below)
  • Password set to the customer registration password
  • Registration from external/Name set to the CPE’s hardware-ID (NetBIOS name) PBX Password ticked

See also #Configuration of customer related objects in the customer’s PBX and SBC

Media-PBX

Services

The media-PBX needs to have http access to the customer PBXs in order to play e.g. announcements or voice-mails. This is why the HTTP client credentials for URLs http:// and https:// via paccess@hoster.tld have to be set as explained above.

PBX

  • One PBX-type object per customer. Both Name and Long Name set to the customer id, “Number” set to #+uniq number out of customer id.
  • One Gateway-type object HTTP-EXT with no number. This takes registrations from customer PBXs to for media data
  • User-type object MOH with number ###10. This is to register the MoH source
  • User-type object TONE with number ###11. This is to register the TONE interface
  • User-type object HTTP-OUT with number ###12. This is to register the media-PBX’s local HTTP interface to offload media data such as WQ announcements and voicemail

Customer PBX

Each customer has a unique customer-id which is used to derive various names and identifiers (see above). It is derived from (part of) the customer’s name and a sequential number. Something like e.g. Kuenkel00001.

The customer PBX is located within the private part of the PBX hosting provider’s network. Because of this, it cannot send media data to the CPE (which is the end customer’s private network). Media has to be sent via the associated Media-PBX thus, as this is dual-homed.

  • the associated SBC is used as Time Server
  • Unknown Registrations is turned on with With PBX Pwd only. This is to enable ZAD (Zero Admin Deployment) for CPE
  • System Name set to the customers email domain (even if it is googlemail.com or yahoo.de as it does not need to be unique
  • PBX Name set to the customer ID

Global Objects in the Customer-PBX

default Template
  • Config Template-type object with Name default
  • Hide from LDAP und Critical
  • Store Phone Config
  • all check-marks ticked in the License tab
  • the Access column needs an entry for @customer.tld (this is the System Name from the PBX configuration) with all check-marks ticked
  • within the Config column, there is only a setting for LDAP Config (Directories) as follows:

<phone> 

 <loc cc='country-code' ac='area-code' ntp='0' itp='00' pbx='subscriber-number'/>
 <ldap id='2' 
   tls='1' port='ldap-port-map-to-pbx-on-sbc, e.g. 9004'/>
 <ldap id='3' 
   enable='1' tls='1' mode='basic' 
   addr='sbc-ip-address' port='ldap-port-map-to-metadir-on-sbc, e.g. 9007' 
   dn='PBX Name' pw='??' base='dc=PBX Name' 
   attr='sn,givenName,company' phone='telephoneNumber:D,mobile:M,:@'/>

</phone>

pw for ldap id 3 is critical: this allows everyone access to the customer directory data via LDAP. If this is not acceptable, the password needs to be removed from the template and configured manually by the end customer

Configuration of customer related objects in the customer’s PBX and SBC

From an administrative point of view, no configuration specific to the individual device should be necessary for registration of a CPE. The default NetBIOS name (e.g. IP232-01-02-03) is used as registration name thus. This must be used as Registration from external in the corresponding SBC object thus (for each potential CPE, there must be one SBC object on the associated SBC, see above). The registration password used by the CPE and thus the Password in the SBC object must be set to the customer registration password (which is specific to this customer, not to the CPE). The Long Name as well as the Name for Registration to internal PBX in the SBC object (hence the registration name for the CPE set in the customer PBX’s user-type object) is a combination of the customer ID and a sequential customer CPE ID, e.g. . Kuenkel00001-001. The customer CPE ID starts with 0 for each customer. This allows for more meaningful data when viewing traces from e.g. the SBC. Moreover, this scheme allows for nice filtering the object view on the PBX by customer name. The password to register the SBC objects from the SBC to the customer PBX is always the globally used PBX password. Hence the PBX Password check-mark must be ticked in the Registration to internal PBX area of the SBC object on the SBC and the PBX Pwd check-mark in the Devices area of the user object in the customer PBX. Initially though, no Devices shall be present in the user object, as this allows ZAD for the CPE.

Update Server

Tasks:

  • Staging (e.g. installation of suitable trust list for HTTPS)
  • Firmware update
  • Backup of configuration data for CPE and customer PBX

Backup of CPE data is done to the virtual CF card of the customer PBX. Backup of customer PBX data is done to its SBC. There is no device or device-type specific update script. Structure on the customer PBX 

/DRIVE/CF0/
  update/
    backup/
      backup-mac-date.txt

The backup folder on the customer PBX (/DRIVE/CF0/update/backup/) must be set writable but not readable under Services/HTTP/Public compact flash access so that CPEs can write their backup.

Firmware files are stored on a folder of the associated SBC. Although this implies that they need to be duplicated to all SBCs, it simplifies the configuration and distributes load.

The generic update scripts are stored in (/DRIVE/CF0/update) on the SBC. staging.txt is the CPE staging code, update.txt the regular update script. Both scripts make extensive use of update variables.

Staging proceeds in 3 steps:

This is a publicly available web service, (this service is currently experimental!) relates a requesting device to the hosting provider and customer pbx based on the serial number. If the device can be identified, the update server URL is rewritten to the PBX hosting provider’s appropriate SBC (based on data that is defined in my.innovaphone).
  • CPE executes the SBC-wide staging script (staging.txt). This performs some init-only tasks
  • CPE executes the SBC-wide update script (update.txt). This performs day-to-day tasks (such as backup)

File structure on SBC 

/DRIVE/CF0/
    update/
      staging.txt           - staging script
      update.txt            - regular update script 
      global.txt            - overrides for global settings
      local.txt             - overrides for SBC-local settings 
      set-customerid.txt    - overrides für customer specfific settings
      staging/              - special staging scripts 
        global.txt            - overrides for global settings
        local.txt             - overrides for SBC-local settings
        set-customerid.txt    - overrides für customer specfific settings
        dev-IPxxx.txt         - device type specific settings 
        cfg-phone.txt         - device class specfific settings 
        cfg-gateway.txt       - ditto
      firm/                 - firmware
        nnnnnn/
          bootxxx.bin
          ipxxx.bin

In order to be accessible during firmware updates, the drive (/DRIVE/CF0/update/firm/) must have read (and only read) access on the SBC under Services/HTTP/Public compact flash access. In order to be accessible from the devices, drive /DRIVE/CF0/update) needs to be readable (and only readable). Both can be achieved with a single /DRIVE/CF0/update/ entry.


Assigning the initial update URL ( http://145.253.157.4/redirect.php ) to CPE is fort further study. It can be done as usual (DHCP), but this requires co-operation by the end-customer which may be a problem. Of course it can also be pre-configured by the hosting provider. In the latter case, the URL must be configured to the device after any long reset (factory settings).


Update Script Security

Update scripts may include registration password (although encrypted) to facilitate automatic registration with almost no user intervention (cf. set-customerid.txt above). By definition, staging scripts are readable by everyone (as they are used to configure otherwise unconfigured devices, so no kwowledge of credentials can be assumed). There is no easy way around this. One option would be to define a password for the web site hosting the scripts. This would then imply that the password needs to be configured to the CPE, which is undesirable from an administrative point-of-view. Moreover, with innovaphone gear (that is, when a web server internal to an innovaphone device is used), the only way to secure the scripts with a password would imply to use an admin account and password – clearly unacceptable from a security point-of-view.

Deployment

Initial

Create once-only services

  • Kerberos and Kerberos Backup
  • Create a new account for the PBX hosting provider in my.innovaphone (if the generic staging is to be used, see above)
Shared Services

Create services shared by a set of customers:

  • SBC
  • Media-PBX
  • Metadir
  • Reporting LinuxAP
  • Fax Linux-AP
  • copy update/staging scripts (global.txt, cfg-*.txt, dev-*.txt) tot he SBC drives (those are identical on all SBCs)
  • create appropriate local.txt on SBC
New Customer
  • create IPVA with customer PBX
  • create appropriate set-customer-ID.txt on SBC
  • create appropriate user objects on customer PBX as well as corresponding SBC objects on SBC
  • create project for customer in my.innovaphone, set URL to the PBX hosting provider’s staging.txt on the appropriate SBC (e.g. https://212.124.38.120/DRIVE/CF0/update/staging.txt) and the encoded public key of the hosting providers RootCA as Trust (as taken from a config file)
CPE
  • Add device tot he customer project in my.innovaphone
  • factory reset (optional, of course)
  • set http://145.253.157.4/redirect.php as Command File URL in Services/Upate
  • wait for or force poll
  • CPE registers with the SBC and customer PBX as _UNKNOWN_

On-Site (Customer) Support / Debugging

  • Alarms, events and syslog are concentrated to the customer PBX
  • Configuration is backed up tot he customer PBX CF
  • All devices (including CPE) have joined the Kerberos domain. So all administrator should be able to log in (provided they have access to the customers network, TeamViewer is an option)

Reporting (Multiple PBX)

NEEDS TO BE UPDATED (TLE)

The LinuxAP VM for reporting needs to have quite a large CF to be able to store all CDR data for a reasonable time period.

  • VMWare disk size should be 50GB initially. This is based on a rough estimate of 200 customers and a time frame of 1 year
rough estimate. Time will tell
  • RAM 1GB


Naming Conventions

To grant access for customers (and reseller) to the Reporting login page (https://Reporting-IP-Adress/apps/innovaphone-reporting/user/login.php), it's nessesary to create a cdr filter called "base filter" and a user login which is bound to this base filter. These logins and filters can only be edited and created by the hoster (i.e. cloudkom). Since the customer can't change his credentials we use the "customer ID" and the "customer registration password" for further steps.

As we mentioned in chapter "Customer PBX" every customer has a uniqe PBX name but customers can have the same "System Name". For this reason it's nessasary to set the Grouping-ID in the Reporting application to "PBX Name" (menu config -> PBX). Never change this setup because filters are depending to the Grouping ID!

Filter parameters for customers:

  • Base Filter: <leave it empty>
  • Filter Name: <customer ID> (which is the PBX Name, i.e kuenkel00001)
  • PBX Name: <customer ID> (which is the PBX Name, i.e kuenkel00001)

User configuration for customers:

  • Name: <customer ID>
  • Password: <customer registration password>
  • Base Filter(s): <customer filter name>

For reasons of billing (or whatever) it could be fine for resellers to have a filter for all of -his- sold PBXs

Possible filter parameters for reseller: (in fact, the reseller id is a customer id, because the only difference is the filter content)

  • Base Filter: <leave it empty>
  • Filter Name: <reseller ID> (i.e. innovaphone00001)
  • PBX Name: <customer ID> +
  • PBX Name: <customer ID> +
  • PBX Name: <customer ID> ...

User configuration for reseller:

  • Name: <reseller ID>
  • Password: <reseller registration password>
  • Base Filter(s): <reseller filter name>

Konfiguration Reporting

  • PBX-Name
  • Filter für PBX VM9 und VM10 erstellt
  • User angelegt die diesen Filter verwenden
  • Reportin Login Page
  • Mit user/passwd:ckl_report/callme38 anmelden, dann sieht man nur calls aus PBX VM10
  • Mit user/passwd:inno_report/callme38 anmelden, dann nur calls aus PBX VM9 sichtbar

Konfiguration Kunden-PBX

Gateway / CDR0
  • Type Remote-AP-S
  • Address Reporting Linux-AP
  • Port 443
PBX / myPBX / Call List Service
  • Type Remote-AP-S
  • Host SBC-IP-addr:Reporting-User-HTTP-Map-Port-auf-SBC
  • User innovaphone-reporting ?????

pass: reporting

Fax Server

NEEDS TO BE UPDATED (afI)

A LinuxAP VMware disk size of 50MB should be sufficient. VM sollte von Anfang an eine Plattengröße von 50MB haben!

Da das FAX-Interface im Öffentlichen Netz stehen muss, um T.38 Pakete empfangen zu können, wird dieses von der CustomerPBX auf Media1 Gateway ausgelagert. Die SOAP-Verbindung wird trotzdem auf die CustomerPBX aufgebaut.

Routing fax.png

Mail to Fax Gateway

Für Kunden, auf deren POP3 Server aus Cloudkom Netz nicht zugegriffen werden kann, wird ein SMTP Server auf Basis von IP-AP aufgestellt. Dort können die Kunden dann per E-Mail die Faxe anliefern. (<mantis-issue id=89710/>)

Use Case "Fax verschicken":

  • Kunde schickt aus dem E-Mail Programm ein Mail mit PDF-Anhang an z.B. +497031730099@fax.cloudkom.com
  • Rufnummer für Zielfax muss im User Part der To: Mailadresse stehen (im Beispiel ist es +497031730099)
  • Das passende Postfach für Fax Server des jeweiligen Kunden wird anhand der From: Mailadresse bestimmt.

Damit die From: Adresse nicht gefaked werden kann, werden nur authentifizierte SMTP-Verbindungen zugelassen. Der Kunde muss dazu bei sich im Exchange einen "SMTP Send Connector" für die Domäne fax.cloudkom.com einrichten ([1]) mit Basic Auth over TLS.

Als SMTP-Server kann man ein Postfix mit Postgresql Erweiterung nehmen, damit man die Kunden Daten (Domains, Postfächer, Logins) direkt aus der Fax Server Datenbank lesen kann.

Als POP3-Server (damit Fax Server die Mails lesen kann) wird dann Dovecot eingesetzt.


Beschreibung der Implementierung: E-Mail_Fax_Server_Gateway_(Project_Cloudkom).

Directories

There are 2 services provided to customers:

  1. the PBX directory
  2. an optional company-wide directory (external LDAP)

PBX Directory (extensions)

  • one NAT port map is to be created per customer on the SBC for port LDAPS (TCP source port xxx to target Port 636)
Port numbers to use???? Sga
This port can be used in the phone’s Port field in the PBX area in Phone/User/Directories/PBX. The PBX LDAP server’s IP address is implied from the registration data. This way, the CPE will in fact access the customer PBX’s LDAP server as opposed to the SBC’s one
  • LDAPS can be used safely, as the CPE’s LDAP client does not verify the certificate anyway (although it would be trusted as it is derived from the PBX hosting provider’s RootCA)

External Directory

Estos Metadir
  • there is one Metadir server per SBC which serves all customers associated with this SBC. Hence there is one inbound NAT port map that maps one port to the Metadir server’s LDAPS port. This map is used from all customers. Customer specific directories are implemented as logical views in the Metadir LDAP server, not as separate servers

Port numbers to use???? Sga

  • there is thus one distinct LDAP node (dc=customer-ID) per customer
  • there is also one distinct replicator for each customer (which is used to import the customers directory data in to the Metadir)
    • Replicator
      • The customer would provide its contact database as „comma separated CSV (Windows)“ file (e.g. as exported from Outlook
      • The file must have columns "Surname","Firstname","Company","Busines Phone ","Mobile Phone"
      • All numbers must be in E164 format, e.g. +49703173009123
      • File name is contacts.csv
      • The is uploaded to the SBC’s CF-file system
      • Each customer has its own directory (https://212.124.38.120/DRIVE/CF0/directory/Kunden-ID) on the SBC. This is the place contacts.csv has to be uploaded to. For this to work, the path must be set to write-only on the SBC!
      • Customers can use e.g. curl. Syntax: curl --verbose -k https://212.124.38.120/DRIVE/CF0/directory/customer-ID/ -T contacts.csv. Note that standard WebDAV clients will probably not work due to the fact that this directory is write-only

Structure on SBC 

/DRIVE/CF0/
    directory/                  - write-only w/o authentication
      Kunden-ID/           
        contacts.csv
  • Metadir has a duplicate of the SBC’s directory structure
    C:\directory\
      script.bat                - script that retrieves customer directory data <code>contacts.csv</code>  from the SBC, called by replicator
      contacts.csv              - sample 
      Kunden-ID\           
        contacts.csv           - customer data
  • Metadir’s per-customer replicator imports the local contacts.csv when run. Before doing so, it calls script.bat which retrieves the appropriate contacts.csv from the SB (this behavior needs to be configured in Metadir, Database Wizard, Zusätzliche Anwendungen).
script.bat copies the then-current customer’s contact.csv from the SBC using curl (curl - syntax: curl --verbose -k -u user:password https://10.30.255.0/DRIVE/CF0/directory/%1/contacts.csv -o c:\directory\%1\contacts.csv
user:password in script.bat are administrator credentials valid on the SBC (as contact.csv files are read-only, see above)
  • Each replicator will be run every 3 hours
The replicator can also be triggered from the cmd-line (calling e.g. TextReplicator.exe as found in the Metadir installation directory. Start a replicator from the GUI and have alook at lastreplicator.bat in the install directory). This may be useful if the PBX hosting provider has implemented a user portal to upload the contact data.
  • The replicator is created using the Replicator-Wizard and associates the .csv columns to the respective LDAP artibutes/DB field names. A combination of all attributes is used as primary key
Replicator Overview
  • LDAP-nodes:
    • LDAP node access authentification is based on distinct, per-customer users, username (=customer ID), password(=customer registration password). No IP address restriction
    • profile is Default always, no customer specific profile required (this is handled using the phone’s Dialing Location)
    • Settings can be seen in the screenshot

Here is how to export contact data from Outlook 2010: 

SGA: stimmt das wirklich mit dem exportieren?
    • man kann nur eigene Kontakte exportieren. Hat man nur eine globale Kontaktliste, muss man diese Kontakte erstmals in die eigene Kontakte kopieren. (IP Kontakte -> Rechtsklick -> kopieren -> eigene Kontakte auswählen)
    • From Outlook File -> Open -> Import -> Export to file -> comma separated values (Windows) -> (select contact folder) -> "Benutzerdefinierte Felder zuordnen" -> Nachname, Vorname, Firma, Telefon geschäftlich, Mobiltelefon auswählen -> Finish
  • LDAPS
    • Just any certificate will do on the metadir, as the LDAP client does not validate the certificate
    • Metadir uses port 714 for LDAPS, SBC needs an appropriate NAT Map
LDAP-Client
  • directory settings should be set in a PBX Config template-type object in the customer PBX and applied to all user objects there
Phone/User/Directories/External LDAP Server Settings
Dialing Location settings need to be done according to the customers trunk line settings
myPBX
  • external directory lookups for myPBX are done by the PBX rather than by the myPBX client itself. The directory configuration is taken from the users phone configuration (as stored in the PBX). This of course presents a problem as the phone configuration will use the external SBC NAT map data for the Metadir, wheras the PBX itself – sitting in the PBX hosting providers private network – needs to use Metadirs private address. There is a special configuration parameter for the PBX which sets the LDAP configuration used for any directory lookup performed for myPBX:
config add PBX0 /ldap-default-addr local-ip-addr-of-metadir /ldap-default-port 714 (714 is Metadirs LDAPS port)

Voicemail

Voicemail is run on the customers PBX as usual. However, as discussed before, the Webmedia (a.k.a HTTP) interface on the media PBX must be used. VM xml script and recorded voice mail files are stored on the customer PBX’s CF card as usual though. The trick is to have a registration to the customer PBX’s voice mail object. If this is present, voice mail will use this registrations to terminate media data rather than the local Webmedia (which is the default).

The registration on the local VM object needs to connect calls to the remote HTTP interface on the media PBX. This is implemented using a GWx interface in the customer PBX’s gateway level which registers to the VM object. There is a route from this GWx to the GWy which in turn registers with the media PBXs HTTP-EXT object (there are no calls to the VM object ever).

PBX

  • voicemail-object
    • Hardware-ID = vmrelay
    • Script-URL (installed on local CF Card as usual) = https://customer-PBX-IP-address (not 127.0.0.1!)/DRIVE/CF0/vm-de/vm.xml?$_divconn=false (this URL will be evaluated on the media PBX, this is why 127.0.0.1 will not work!)
    • suitable extension depending on customers numbering plan

Gateway

    • vmrelay GWxx, Register as Gateway, 127.0.0.1, Name= vmrelay
    • Route GWxx (vmrelay) --> ###12 GWyy (HTTP-EXT)

MWI

Simpkly works as is.

Mail MWI

Mails are sent through the PBX hosting provider’s own mail server. This may require authenticated SMTP. This needs to be configured in each email.xml in the customer PBX’s voice mail installation:

  • message sender
  • Subject of MWI mail
  • mail server
  • credentials

Apart from the mail subject (which is language dependant), this is identical for all customers, so it can be done once and copied then.

User Email addresses must currently be set in each user object’s URL attribute (or in a separate file in the user directory).

Operator

TBD

Backup

Disaster recovery backup ist o be done by the operator of the VMware infrastructure.

User data (PBX config, CPE configuration) is backed up by the update server as outlined above.


UI/Portal

Innovaphone does not supply a dedicated UI for hosting scenarios (neither for the PBX hosting provider nor for the end customer). It is envisaged that hosting providers will craft their own tool for this, as this is highly related to the provider’s business model.

Retrieved from "https://wiki.innovaphone.com/index.php?title=Howto:Hosting_with_V10&oldid=29325"