Reference11r1:Concept H.323 over TCP/TLS (H.460.17)

The standard H.460.17 is an extension to the H.323 standard. It defines a mode of operation to use a single TCP or TLS connection for RAS and call-control within H.323. This is done by tunneling the RAS messages within H.225 signaling messages. This simplifies or even allows different NAT or firewall traversal scenarios. This feature is available starting with version 11. In case of TLS device certificates can be used for authentication of phones at the PBX.

Configuration

Two new protocol selections are available on the phones and in gateway configuration: H.323/TCP and H.323/TLS.

On the PBX incoming H.460.17 registrations are accepted default. There is a new checkmark on devices 'TLS only' which can be used to only allow H.323/TLS registrations.

In case of TLS, the device certificate can be used for authentication, instead of the password. If a registration with Hardware ID is done, the CN of the device certificate is checked against the registration name. This way the phone can be authenticated towards the PBX without the need to configure any credentials on the phone.

Important: Please note that all devices for H323 / TLS must have a valid time, otherwise no registrations are possible. If you can not reach your NTP server, you can use the ctime command to configure a static startup time.

Homeoffices without VPN

Together with ICE, this feature allows the use of phones in home offices without the need of a VPN connection. Even the PBX may be located inside a private network, provided there is a single mapping on the NAT router to map incoming TCP connections to port 1300 (the well-known port for H.323 over TLS) to the PBX. If you use H.323/TCP and not H.323/TLS the port to be mapped on the NAT router it's 1720.

Known Issues

• Certificate based authentication only works if the PBX trusts the certificate presented by the phone. Some very old innovaphone phones use a self-signed certificate instead of the one which is derived from the innovaphone Device Certification Authority. Such certificates are usually not accepted. You can check the device certificate by looking at the Device certificate in General/Certificates. If it shows C=DE, O=innovaphone, OU=innovaphone Device Certification Authority as Issuer, it is a valid certificate. If it shows itself as Issuer (that is, if Subject and Issuer are equal), it is a self-signed certificate.

• The PBX must have the "innovaphone Device Certification Authority" - certificate in its own Trust-list, otherwise it will reject the phone certificates signed by it. When a device starts up, it will examine its own device certificate and and put all certificates found in the certificate chain in to its own trust list. As explained above, some very old innovaphone device might miss the proper device certificate. As a result, the certificates in the trust list will be missing too. To solve the problem, you can download the certificate from another device and upload it in the trust-list of the device running the PBX.

• During installation, the innovaphone Softwarephone and innovaphone myPBX for Android generate a self-signed certificate which is not "issued" by the "innovaphone Device Certification Authority" (for security reasons). Due to this the PBX will reject the softwarephone/myPBX Android certificate signed by it. To overcome this it is necessary that the self-signed certificate by the "endpoint" is added to the trust-list of the PBX, or a new certificate is assigned to the "endpoint" issued by an CA that is trusted by the PBX. It is recommended that the CN value for the certificate must be always unique to avoid issues of duplicate HW-IDs on the PBX which is not possible.

• In case of innovaphone myPBX for Android the certificate needs to be copied to the PBX another time if myPBX Android was de-installed and re-installed because then myPBX Android starts with a clean vars directory and the certificate is generated freshly with random numbers. This doesn't apply to the innovaphone Softwarephone since it will keep the same CN value (MAC of the PC).

• The Gatekeeper Discovery can not be used with TCP/TLS - you must define the Gatekeeper Address in order to get H.323 Registration via TCP/TLS working.

• Since V12, H323/TLS registration will also work with user/password only provided by the endpoint, even if the CN of the certificate doesn't match with the HW-ID value for registration at the User Object. For this to work, the flag "TLS Only" must be deactivated. This mechanism is useful for usecases with Softwarephone or myPBX APP. However the PBX must still trust the certificate of the endpoint so the SSL connection could be established.

• On IP62 following preparations must be met, to be able to authenticate with client certificate:
  • Client certificate must be installed using WinPDM software. The CN of the certificate must match with the MAC address of IP62 and must be trusted on the PBX. Note: The IP62 are delivered without stock certificate provided by the innovaphone Authentication Authority.
  • Set the MAC address of the IP62 in WinPDM under VoIP->General->Endpoint ID. Use the same value as 'Hardware ID' of the 'Device' on the User Object.
  • Set VoIP->H.323->H.323 Transport to TLS
  • Set VoIP->H.323->Listening Port to 1300
  • Set VoIP->H.323->Registration Identity to Endpoint ID

See also

• Reference11r1:Concept Using PBX services from public internet (v11 and before)
• Reference12r1:Concept Reverse Proxy, Course12:Advanced - Reverse Proxy (v12 and later)