innovaphone wiki - User contributions [en]

Howto:Trizwo Jitsi App - trizwo GmbH IT & Communication - Partner App

2022-01-26T13:20:04Z

Erik:

[[Image:Trizwo_Jitsi_App_Logo.png||200px|right]]

==Product Name==

[https://www.trizwo.de/apps/trizwo-jitsi-app trizwo Jitsi App]

==Certification Status==




<span style="color:red">Not yet given due to missing app in store</span>

==Category==

[[Category:Partner_Apps|{{PAGENAME}}]]
{{Category:3rdParty_Conferencing_/_Video_Systems}}
[[Category:3rdParty_Conferencing_/_Video_Systems|{{PAGENAME}}]]

==Vendor==

[[Image:Trizwo_Logo_horizontal.png]] [http://www.trizwo.de trizwo GmbH]

==Description==




The trizwo Jitsi App allows to join Jitsi videoconferences from inside innovaphone myApps. It consists of an administrator part and a user part.

==Functions==


Short summary of the most important features:
*video call
*chat

With the trizwo Jitsi App videoconference rooms are simple to create and operate for adminitrators. Just the server name has to be entered to create a room link. Additionally, it is possible to create various rooms with different categories which are all saved in the Jitsi App.
Users will be able to access all rooms in the app for which they are authorized. They are able to enter a videoconference by merely clicking on the room button or link.
(Extensions of additional features are in process.)

==Licensing==


None

==Versions==


===Compatible innovaphone firmware versions===

* innovaphone V13r2

===Application versions used for interop testing===


* trizwo Jitsi App: 131004 sr10

* innovaphone V13r2 sr6

==Configuration==









For configuration, please refer to [https://www.trizwo.de/apps/trizwo-jitsi-app the manual on our website].

==Contact==


{|
| colspan=99 | trizwo GmbH IT & Communication
|-
| colspan=99 | Biedenkamp 1A
|-
| colspan=99 | 21509, Glinde
|-
| Tel: || +49 40 611980 0
|-
| Fax: || +49 40 611980 21 0
|-
| Mail: || [mailto:info@trizwo.de info@trizwo.de]
|}

[[Category:Compat|{{PAGENAME}}]]

Reference12r1:Concept Reverse Proxy

2018-12-12T08:11:44Z

Erik:

[[Category: Concept|Reverse Proxy]]
The Reverse Proxy is a software module, which is available on innovaphone gateways. It is designed to allow safe access to services of the innovaphone PBX from the public internet. To accomplish this the gateway must be accessible from the public internet either by NAT port forwarding, or directly. The reverse proxy forwards traffic to configurable destinations.
The access to internal destinations can be limited in several ways and algorithms to detect attacks are implemented, which are used to put ip addresses into a blacklist.
The reverse proxy supports H.323, SIP, HTTP and LDAP over TCP or TLS.

== Configuration ==

The reverse proxy only accepts any connections on the supported protocols, if the port numbers for these protocols are configured. The well-known port numbers or
non standard port numbers can be used for these protocols.

A timeout may be configured until which an entry in the blacklist is removed automatically.

A threshold suspicious requests per minute can be used to tune detection of attacks.

Forwarding to internal destinations is based on the addressed host. For this the received requests are analysed and for each supported protocol different elements are used to identify the addressed host.

== Basic Operation ==

Connections are accepted on the configured port. The received protocol is analysed to determine the addressed host and a internal connection is established to this host. If the incoming connection is TCP for the internal connection TCP is used as well, if the external connection is TLS, for the internal connection TLS is used. If only TCP or only TLS is configured for the internal connection it is used regardless if the incoming connection was TCP or TLS.

If the Check Certificate checkmark is set, for the internal connection TLS is used only if the received certificate matches the user name within the protocol. This way a host receiving a request through the Reverse Proxy using TLS can assume that the connection was authenticated using a valid certificate, which matches the user.

Access to a configured protocol may be limited to certain networks. This is done by configuring a list of networks in a addr:mask form.

=== H.323 ===

For H.323 registrations, the gatekeeper identifier received in GatekeeperRequest or RegistrationRequest messages is matched to the Name configured for the host. Only H.323 over H.225 (H.450-17) is supported.

For calls without registration a destination in the for <user>@<domain> is expected. <domain> is matched to the Name configured for the host. This can be used for H.323 open federation.

=== SIP ===

For SIP registration the domain part of the FROM header of a REGISTER message is matched to the Name of the configured host.

Also SIP INVITE messages are forwarded by the Reverse Proxy, if the FROM URI matches with the configured host.

=== HTTP ===

For HTTP requests the host header is matched to the Name of the configured host. If within a single TCP/TLS connection requests are sent to different hosts, the outgoing connections are terminated and for the request to the other host a new connection is established.

The path which may be accessed can be restricted, by configuring the allowed path. If the pass is configured with a trailing '/' no access to folders inside this path is allowed.

=== LDAP ===

For LDAP the LDAP_BIND message is analysed. A user in the form <domain>\<user> is expected and the <domain> is matched to the domain part of the name of the configured host.

== Attack detection ==

Attacks are detected based on the frequency of unsuccessful requests. If more then a configured number of such requests are received within a sliding window of 1min the originating IP address is put into the black list.

To provide some indication about current suspicious requests a list with the the 10 remote IP addresses with the highest number of requests is displayed.

== Blacklist/Whitelist ==

A blacklist/whitelist mechanism is used to block IP addresses or grant access to IP addresses regardless of attack detection. An entry into list can be configured with a timeout, so that it will be removed after the timeout automatically. Entries generated by the attack detection use the configured timeout.

A blacklist entry can be easily changed to a whitelist entry by setting the whitelist checkmark.

== Reverse Proxy with innovaphone PBX ==

The innovaphone PBX has some features implemented especially for integration with the Reverse Proxy.

=== Controlling Authentication ===

On the innovaphone PBX up to 8 Reverse Proxies can be configured which are used to forward requests to the PBX. A Reverse Proxy is identified by its IP address. Optionally a certificate name can be configured for a Reverse Proxy, to verify that the connection really sent by the Reverse Proxy and not just relayed by some other equipment.

Registrations through a Reverse Proxy are only accepted if the Reverse Proxy flag at the destination device is set. This way no unexpected registration is possible. When the Assume TLS checkmark is set, a registration received from the Reverse Proxy via TLS is assumed to be authenticated with a proper TLS certificate on the Reverse Proxy already. So no further authentication is required on the PBX. Such a registration is accepted also if TLS Only is set on the device.
If a registration from the Reverse Proxy is received via TCP password authentication is required.

=== Support for multiple Slave PBXs ===

To address a specific Slave PBX through a Reverse Proxy, a GK-ID with the format <domain>/<location> can be used. A PBX ignores anything in the GK-ID after the '/'. This way in the Reverse Proxy for each slave PBX sharing all the same domain a separate host entry can be configured.

On the phone this format can be used to address the correct destination PBX.

If the registration redirect mechanism shall be used, so that all client can share the same configuration, normally the PBX redirects to the IP address of the correct slave. In this case this does not work since from the public internet the internal addresses are inaccessible, so DNS Names must be configured on all PBXs. In the external DNS these DNS names must all be resolved to the Remote Proxy. The PBX changes the redirect GK-ID to contain the new location in the above format.

The physical location of the phone in case of redirection is the PBX to which the first registration was made. The PBX uses the <physical-location>@domain... format of the GK-ID on redirection.

Physical location and registration PBX can be configured manually on the phone by using a GK-ID of <physical-location>@domain/<registration PBX>

=== Support for Standby PBXs ===

To address different PBXs for the primary and the alternate registration different GK-IDs have to be used for the primary and alternate (standby) PBX in the form of <domain>/<location> with a different location for primary and alternate. This way in the reverse proxy different host entries can be configured to address the active and standby PBX.
To configure this on innovaphone endpoints a GK-ID in the form <domain>/<primary>:<alternate> can be configured. For the primary registration <domain>/<primary> and for the alternate registration <domain>/<alternate> is then used.

=== SIP Federation over Reverse Proxy not functional ===

Reverse Proxy supports SIP INVITE this allow us to have a SIP Federation interface working through the RP to make audio/video and chat calls in theory however SIP SUBSCRIBE message isn't supported by the RP this means that Presence sharing doesn't work so SIP Federation will not work 100%.

Reference12r1:Concept Reverse Proxy

2018-12-12T08:11:00Z

Erik: LDAP: Bind is matched to domain of the host, not to the name

[[Category: Concept|Reverse Proxy]]
The Reverse Proxy is a software module, which is available on innovaphone gateways. It is designed to allow safe access to services of the innovaphone PBX from the public internet. To accomplish this the gateway must be accessible from the public internet either by NAT port forwarding, or directly. The reverse proxy forwards traffic to configurable destinations.
The access to internal destinations can be limited in several ways and algorithms to detect attacks are implemented, which are used to put ip addresses into a blacklist.
The reverse proxy supports H.323, SIP, HTTP and LDAP over TCP or TLS.

== Configuration ==

The reverse proxy only accepts any connections on the supported protocols, if the port numbers for these protocols are configured. The well-known port numbers or
non standard port numbers can be used for these protocols.

A timeout may be configured until which an entry in the blacklist is removed automatically.

A threshold suspicious requests per minute can be used to tune detection of attacks.

Forwarding to internal destinations is based on the addressed host. For this the received requests are analysed and for each supported protocol different elements are used to identify the addressed host.

== Basic Operation ==

Connections are accepted on the configured port. The received protocol is analysed to determine the addressed host and a internal connection is established to this host. If the incoming connection is TCP for the internal connection TCP is used as well, if the external connection is TLS, for the internal connection TLS is used. If only TCP or only TLS is configured for the internal connection it is used regardless if the incoming connection was TCP or TLS.

If the Check Certificate checkmark is set, for the internal connection TLS is used only if the received certificate matches the user name within the protocol. This way a host receiving a request through the Reverse Proxy using TLS can assume that the connection was authenticated using a valid certificate, which matches the user.

Access to a configured protocol may be limited to certain networks. This is done by configuring a list of networks in a addr:mask form.

=== H.323 ===

For H.323 registrations, the gatekeeper identifier received in GatekeeperRequest or RegistrationRequest messages is matched to the Name configured for the host. Only H.323 over H.225 (H.450-17) is supported.

For calls without registration a destination in the for <user>@<domain> is expected. <domain> is matched to the Name configured for the host. This can be used for H.323 open federation.

=== SIP ===

For SIP registration the domain part of the FROM header of a REGISTER message is matched to the Name of the configured host.

Also SIP INVITE messages are forwarded by the Reverse Proxy, if the FROM URI matches with the configured host.

=== HTTP ===

For HTTP requests the host header is matched to the Name of the configured host. If within a single TCP/TLS connection requests are sent to different hosts, the outgoing connections are terminated and for the request to the other host a new connection is established.

The path which may be accessed can be restricted, by configuring the allowed path. If the pass is configured with a trailing '/' no access to folders inside this path is allowed.

=== LDAP ===

For LDAP the LDAP_BIND message is analysed. A user in the form <domain>\<user> is expected and the <domain> is matched to the domain part of Name of the configured host.

== Attack detection ==

Attacks are detected based on the frequency of unsuccessful requests. If more then a configured number of such requests are received within a sliding window of 1min the originating IP address is put into the black list.

To provide some indication about current suspicious requests a list with the the 10 remote IP addresses with the highest number of requests is displayed.

== Blacklist/Whitelist ==

A blacklist/whitelist mechanism is used to block IP addresses or grant access to IP addresses regardless of attack detection. An entry into list can be configured with a timeout, so that it will be removed after the timeout automatically. Entries generated by the attack detection use the configured timeout.

A blacklist entry can be easily changed to a whitelist entry by setting the whitelist checkmark.

== Reverse Proxy with innovaphone PBX ==

The innovaphone PBX has some features implemented especially for integration with the Reverse Proxy.

=== Controlling Authentication ===

On the innovaphone PBX up to 8 Reverse Proxies can be configured which are used to forward requests to the PBX. A Reverse Proxy is identified by its IP address. Optionally a certificate name can be configured for a Reverse Proxy, to verify that the connection really sent by the Reverse Proxy and not just relayed by some other equipment.

Registrations through a Reverse Proxy are only accepted if the Reverse Proxy flag at the destination device is set. This way no unexpected registration is possible. When the Assume TLS checkmark is set, a registration received from the Reverse Proxy via TLS is assumed to be authenticated with a proper TLS certificate on the Reverse Proxy already. So no further authentication is required on the PBX. Such a registration is accepted also if TLS Only is set on the device.
If a registration from the Reverse Proxy is received via TCP password authentication is required.

=== Support for multiple Slave PBXs ===

To address a specific Slave PBX through a Reverse Proxy, a GK-ID with the format <domain>/<location> can be used. A PBX ignores anything in the GK-ID after the '/'. This way in the Reverse Proxy for each slave PBX sharing all the same domain a separate host entry can be configured.

On the phone this format can be used to address the correct destination PBX.

If the registration redirect mechanism shall be used, so that all client can share the same configuration, normally the PBX redirects to the IP address of the correct slave. In this case this does not work since from the public internet the internal addresses are inaccessible, so DNS Names must be configured on all PBXs. In the external DNS these DNS names must all be resolved to the Remote Proxy. The PBX changes the redirect GK-ID to contain the new location in the above format.

The physical location of the phone in case of redirection is the PBX to which the first registration was made. The PBX uses the <physical-location>@domain... format of the GK-ID on redirection.

Physical location and registration PBX can be configured manually on the phone by using a GK-ID of <physical-location>@domain/<registration PBX>

=== Support for Standby PBXs ===

To address different PBXs for the primary and the alternate registration different GK-IDs have to be used for the primary and alternate (standby) PBX in the form of <domain>/<location> with a different location for primary and alternate. This way in the reverse proxy different host entries can be configured to address the active and standby PBX.
To configure this on innovaphone endpoints a GK-ID in the form <domain>/<primary>:<alternate> can be configured. For the primary registration <domain>/<primary> and for the alternate registration <domain>/<alternate> is then used.

=== SIP Federation over Reverse Proxy not functional ===

Reverse Proxy supports SIP INVITE this allow us to have a SIP Federation interface working through the RP to make audio/video and chat calls in theory however SIP SUBSCRIBE message isn't supported by the RP this means that Presence sharing doesn't work so SIP Federation will not work 100%.

Reference11r2:Interfaces/ETH/802.1X

2018-11-15T14:01:57Z

Erik: Added a reference-link Howto:Security_works_with_innovaphone

;'''EAP-MD5''':
* '''User''' Enter the user/identity to authenticate with.
* '''Password''' Enter the shared secret for the MD5 challenge/response handshake.
;'''EAP-TLS''':
The EAP-MD5 settings are going to reused for EAP-TLS needs. I.e. there's currently no extra setting for EAP-TLS. The configuration for an actual certificate, being fed into the EAP-TLS session, can be found at ''General/Certificates/Device Certificate''.

* '''User''' Enter the user/identity<ref>EAP-TLS doesn't mandate that identity to necessarily be the same as the certificates subject/CN</ref> to be sent within the EAP Identity request.<ref name="user-pw">A non-empty user/password just serves as an "on"-switch</ref>
* '''Password''' Enter arbitrary content.<ref name="user-pw"/>
* '''General/Certificates/Device Certificate'''
;'''Proxy-Logoff''':
If the phone's LAN-port got disconnected, EAPOL-Logoff messages are going to be sent on behalf of participants connected to the phone's PC-port.
An EAPOL-Logoff will be sent for each MAC-address learned from traversing EAPOL-Start messages.

=Notes=
<references/>
[[Concept_802.1X|Concept 802.1X]]

[[Howto:802.1X_EAP-TLS_With_FreeRadius|Howto article: 802.1X EAP-TLS With FreeRadius]]

[[Howto:Security_works_with_innovaphone#802.1X_port_security|Howto article:Security_works_with_innovaphone]]

Reference7:Configuration/General/SNMP

2009-01-19T09:25:20Z

Erik: coreected download-link

The VoIP device allows the operating state to be monitored using '''SNMP''' (Simple Network Management Protocol with version 1.0). Standard MIB II and a manufacturer-specific MIB (Management Information Base) are supported. Detailed information about this MIB can be obtained from a certified innovaphone dealer or downloaded directly in the download area of the innovaphone homepage. It is included in the folder "tools" together with other applications and firmware. File name: INNO-MIB.TXT (http://download.innovaphone.com).

Note: SNMP traps will not be send before an uptime of 90 seconds(will be collected in this time) .Due to DHCP negotiation awaiting

{|
|valign=top nowrap=true|'''Community:'''
| If the standard community name public is not being used, a different community name can be entered in this field.
|-
|valign=top nowrap=true|'''Device Name:'''
| For more detailed information, a device name can be specified here for the SNMP agent.
|-
|valign=top nowrap=true|'''Contact:'''
| As can a contact person (Contact).
|-
|valign=top nowrap=true|'''Location:'''
| As can a location (Location).
|-
|valign=top nowrap=true|'''Authentication Trap:'''
| Access via SNMP is only possible if the correct community name is entered. If this check box is checked, a trap is generated in the case of access with an incorrect community name.
|-
|valign=top nowrap=true|'''Trap Destination:'''
| Destinations for trap messages also have to be defined if the device is to trigger the traps defined in the manufacturer-specific innovaphone MIB.
|-
|valign=top nowrap=true|'''Allowed Networks:'''
| To increase security, access to the device can be restricted by restricting SNMP access to a defined list of computers or IP address ranges. To disable SNMP access completely just enter ''0.0.0.0'' as ''Address'' and ''255.255.255.255'' as ''Mask''.
|}

'''In V7 the SNMP Traps are enhanced'''

All events with type =Alarm are send via SNMP traps.
SNMP Trap delivers: code,severity,txt (e.g interface down) and Alarm –source (e.g IP0/ETH1)

innoDiagAlarm TRAP-TYPE
ENTERPRISE innovaphone
VARIABLES {
trapGaugeParm, -- Alarm Code
trapDisplayStringParm, -- Alarm Source
trapGaugeParm, -- Severity: indeterminate(0),major(1),critical(2)
trapDisplayStringParm -- Alarm Text
}
DESCRIPTION
"This trap corresponds to an alarm under Administration/Diagnostics/Alarms"
::= 6

innoDiagAlarmClear TRAP-TYPE
ENTERPRISE innovaphone
VARIABLES {
trapGaugeParm, -- Alarm Code
trapDisplayStringParm -- Alarm Source
}
DESCRIPTION
"This trap corresponds to an alarm clearing under Administration/Diagnostics/Alarms"
::= 7