Skip to content
Last update: December 7, 2023

Setup Global Green-GO connections

Bridging concept

The Green-GO bridge products can be used to make communication possible between multiple sites. This can be different buildings in a campus or connecting sites all over the world. A Green-GO bridge not only crates a tunnel from site to site like a VPN but it also buffers the audio to accommodate for latency and jitter that is inherent to a routed connection.

By buffering the audio on the bridge the local Green-GO network kan stay lip-sync and bridged connections are free from audio glitches.

One Bridge X has four ports and can make 1 connection on each port. (An original Bridge has 2). Each connection of a bridge can be either in Group or User mode. Giving freedom to tailor connections to specific needs.

A User connection always connects a remote Green-GO device to a bridge port. The remote device then becomes member of the local Green-GO network and has all the features - 32 channels + special channels

A Group connection always connects between 2 bridges. bridging 1 Group of the local Green-GO network to the remote Green-GO network and vice versa. (Note that the groups don't need to be the same on both site's)

Bridging Groups between 2 sites

Having a Bridge X on 2 sites gives the possibility to bridge a total of 4 groups between 2 sites. If all ports of the bridge are utilized there are no more free connections that are available. adding a bridge on both sites will increase the number of available connections and can be extended virtually unlimited by adding bridges.

2 bridges

Bridging Groups between 3 sites

Having a Bridge X on 3 sites gives the possibility to bridge 2 groups from site to site. Each bridge will use 2 connections to both other site's.

Groups that need to be shared between the 3 sites however only require 2 connections One between Site A and C and one between Site B and C. Site A and B then have a routed connection via site C. having a bridge X on each site can share 2 extra groups between site A and B as these bridges have only 2 connections utilized.

3 bridges

Adding an extra Bridge to Site C will even increase this effect by having 4 groups shared between the 3 sites by having only routed connections between site A and B.

4 bridges

Bridging Users

Having a Bridge X allows up to 4 remote Green-GO devices to connect to the local Green-GO network. The remote devices can be on one remote site or sites scattered over the world.

4 devices

Bridging between multiple sites

It is possible to connect more sites all over the world by adding more remote devices or sites with a bridge to make any size of global intercom system possible. There is virtually no limitation in the amount of Bridge connections that can be made to create a multi site intercom system.


Considerations and terms

When setting up Green-GO bridges a loads of scenarios are possible. Each situation is different and choices need to be made depending on the situation.

Depending on the chosen bridge connection method, at least some basic IP and IT knowledge is needed. This section will not try to explain all the technical language used

Local Topology

A bridge has 4 physical network ports. 2 are labeled Internal, 2 External. Each set of 2 Physical ports is an interface and can have its own Network configuration (IP settings).

The Green-GO data is always only present on the Internal interface. Other local Green-GO devices need to connect to internal interface . Normally the bridged data is present on the External interface. This can be changed to the Internal interface.

Routing the bridged data to the internal interface does not have any affect on the functionality and performance of the bridge.

Tip: do not overlap subnets

The Internal and External Subnets can NOT partially overlap, as in this example.

Example IP config Int Network Ext Network
IP address

The internal subnet contains addresses to which also contains the address range of the external network to This will lead to remote device data not sent on the right interface.

A separate LAN for internal and external

Separate networks

Green-GO devices in the local network connect to the internal interface.

Remote devices are connected through the external interface. this can either be devices connecting directly connected to that LAN or routed/via the WWW.

Example IP config Int Network Ext Network
IP address

Upsides for this method:

  • There is strict separation between between internal and external interfaces.
  • It is not possible that third party traffic can interfere with/overload Green-GO entities other than the bridge.
  • Green-GO traffic will not be present on the external LAN, It can also not interfere with third party entities.

Downsides of this method:

  • More physical cables/switch ports are needed, each bride requires 2.

One LAN for all

One network

The other option is to route the "bridged" traffic also to the Internal interface and create one Lan where both the Green-GO devices and the Remote devices are in.

In this case we "disable" the External interface by setting the properties to A Physical connection is only made to the Internal interface. No cable is plugged in the External interface.

The internal Network can either be configured Static or Dynamic. Usually a router will present that also act as DHCP server and hand out IP address

Example IP config Int Network Ext Network
IP address

Where usually the Internal Gateway is the IP address of the on site router.

Downsides of this method:

  • There is no separation between the Green-GO Network and other services.
  • Separation needs to handled by proper implementation on the Network infrastructure.
  • In-proper setup can lead to heavy traffic/overloading on Green-GO entities (not necessarily the bridges).
  • In-proper setup can lead to heavy traffic/overloading on third party devices, as Green-GO relies on multicast and broadcast.

Upsides of this method:

  • Using one LAN for internal and external can be more convenient IF the infrastructure is setup properly.
  • A single cable and network port are used on the IT infrastructure

Why not use a VPN as bridging method

It is possible to create a Site to Site tunnel with a VPN connection between the two sites. The devices then can see each-other. even the Green-GO data will be send from one site to the other.

It might even work. The issue is that these connections are routed. The very nature of these routed IP connections is that there is absolutely no guarantee that the packets arrive to the other site with the same latency or even in the right order. this will make sure of it without a doubt that there will be Jitter in latency on the receiving side. As the System latency of Green-GO is very low there are no buffers large enough to cover this jitter.

A routed connection might work one day but can stop working or give distorted audio the other day. Therefore it is NOT advised to utilize only a VPN connection to bridge between sites.

A VPN can of course be used for other reasons. One being an extra security layer. And port forwarding might not be necessary if both bridges are in the same subnet. Care needs to be taken that the 2 local Green-GO networks can NOT see each-other via the VPN. This can be done by setting up both local Green-GO networks in their own net. Or by blocking the local Green-GO traffic over the vpn (Multi-cast on UDP port 5908 )

Port forwarding

The UDP traffic from one bridge to another is routed as soon as the two bridges are not in the same LAN. for the bridges to be able to setup a connection they must be able to find each-other. this can be done by setting UDP port forwarding on the NAT/router on the passive side.

bridge A can not directly talk to the IP address of a bridge B that is behind a NAT. the the LAN ip of bridge B is not visible to the outside world.

Port forwarding This can be solved by telling the NAT/router on site B to forward a specific UDP port to the ip address of Bridge B.

The flow will be:

Sender Receiver message
Bridge A Gateway A Connection request for IP address of Gateway B on port XXXX
Gateway A Gateway B Connection request for port XXXX
Gateway B My port forwarding table says to forward port xxxx to IP address of Bridge B
Gateway B Bridge B Connection request on IP address of Bridge B port xxxx

Once this is done the 2 bridges can find each other to setup a connection.

Passive side

The side that waits for an incoming connection is called the Passive side.

In Cloud connection this port registers to the cloud service and waits for incoming connections

In IP connection for each Bridge connection port on the passive side a Port forwarding rule needs to be set in the Gateway/Router on that site.

Active side

In a Green-GO Bridging setup the side that initiates the connection. This can be a remote device or a bridge in group active mode

in Cloud connection this ports request an available free port with the corresponding cloud ID

In IP connection the remote device or a bridge in group active mode will connect to the other bridge via the gateway's IP. Port forwarding is NOT necessary on the Active side.

Connection methods

Cloud Connection

Connect though the cloud, use the GreenGO cloud connect service to ease the setup a connection between sites. there is no need to worry about remote or external IP addresses or port forwarding.

Status of Cloud service

The cloud service is still in active development and not deployed at the time of the software release. Updates on the Cloud service will be published on our users forum

The Cloud Service

The Cloud service

The cloud service will handle all the necessary steps to setup a bridge connection. once the connection is established all the audio data is send directly from device to device without the cloud service in between. the service keeps track of this active connection but is not needed to maintain the connection. The cloud service will use a combination of a Cloud ID and a Password to setup a connection.

cloud concept

The cloud service will not only give ease of setup but can also give a much more redundant or failsafe connection. Multiple ports of multiple bridges on the same site can all be given the same Cloud ID and password combination. in the case of a bridge failure the cloud service will dynamically allocate new bridge ports for all open connections.

The Cloud service runs as a primary and secondary service handling failover if one of the two is unreachable

The abstract flow is as following (note that for simplicity all security/verification steps are left out):

%%{init: { 'theme':'forest', 'sequence': {'showSequenceNumbers':true, 'diagramMarginY':5} } }%%
    participant bridge as BridgeX port (passive)
    participant cloud as Green-GO cloud services
    participant device as Remote device

    bridge->>+cloud: register for session id
    note right of cloud: Authenticate connection request<br>and adding port to session ID
    cloud-->>-bridge: port registered
    device->>+cloud: connection request for session id
    note left of cloud: Authenticate connection request<br>and check for available ports
    cloud->>+bridge: expect connection from client
    bridge-->>-cloud: accepted. ready for connection
    cloud-->>-device: initiate connection to available port
    device->>+bridge: connection request
    bridge-->>device: connection accepted
    device-->>cloud: connection established successfully
    bridge-->>-cloud: connection established successfully
    note right of cloud: Mark port as unavailable

Cloud ID

. One Cloud ID can be used for unlimited incoming connections on one passive site. e.g. one site has 2 bridges, all ports are configured in user mode with the same Cloud ID/Password combination. This means that in total 8 devices can connect with this combination from anywhere in the world. adding an extra bridge with the same configuration will register 4 extra ports to the cloud service. in case one of the bridges is disconnected the cloud service will immediately redirect the lost connections to available free ports enabling to create failsafe connections. The allocation of available ports is done dynamically, this means that it can not be predicted to which specific port remote devices will connect if all Cloud ID/Password combinations are the same. For more control to which specific port a device connects different passwords can be used. This can of course limit redundancy, a port with Cloud ID/PW combination A/B can not backup for another port with A/C.

For bridging groups this might require some extra planning and thought. When connecting multiple sites to one "Hub" site all with the group worldwide. The same cloud ID/Password combination can be used. All ports will have the same group assigned. If multiple different groups need to be shared between 2 sites they can both share the same cloud ID but would need a different password. The dynamic allocation of the connections can cause a reconnect to swop the groups around.

Cloud Domain name

All devices can set their Cloud Domain name. By default this is set to default dns this will try to reach the cloud service on A custom Domain name or even a fixed IP can be set for a privately run cloud service. The device wil request to resolve the addresses for primary.domainname and secondary.domainname. if resolved the IP address of the service will be displayed accordingly.


Basic remote users with backup

All Bridge Ports and remote devices are in Cloud ID connection mode and have the same Cloud ID and Password set. a maximum of 4 devices connects to the system allowing for 100% redundancy on the failure of a bridge.

4 remote devices with redundancy

Basic 4 groups between 2 sites

Sites A and B need to share 4 groups. On one of the sites all ports are set to Group Active, The other site to Group Passive.All cloud ID's on all ports can be set to the same Cloud ID. For each Group that that will be bridged a different Password is used, making sure that the groups do get their matching port when connecting. Note: this example does not have any build in fail-save or redundancy

2 sites sharing 4 groups

Hybrid Groups and remote devices

Sites A and B need to share 2 groups and 2 remote devices need to connect to site A. In this case all connections can again use the same Cloud ID. on site A ports 1 and 2 are set to group passive each with their own unique passwords. Site B will do the same but in group active mode. The remaining 2 ports on site A will be set to Any user in Cloud id mode, both with the same password. the remote devices are set to cloud connection with the same combination of Cloud ID and password. Redundancy can simply be added by adding a second bridge with all ports configured identical as the first bridge.

Hybrid groups and devices

complex system with multiple Cloud ID's

Sites A,B,C and D all need to share the same "global" group. Furthermore site B needs to share 2 private group with sites C and D. this can not be done with one Cloud ID/Password combination.

Site A will set 3 ports to group passive with Cloud ID password combination A. Sites B,C and D setup one port in group active with the same combination A.

Site B will set 2 ports in group passive with each a unique ID/Password combination. Sites C and D will each use one of these combinations for a port in Group active mode.

complex example

Search IP connection

The Search IP connection is a semi automatic method of connecting remote devices on a single LAN with un-routed connections but unreliable timing like wifi or VPN links. The key is that the remote device or active bridge port are on the same subnet as the passive bridge port. Internet(cloud) access is not needed.

Search IP Connection Setup

To Setup a Search IP connection the Passive Bridge port is setup as usual except that the UDP port can be left to "00000" this will trigger dynamic assignment of the UDP port. in that case the Password is the unique identifier for a connection.

The Active side, Bridge port, Remote device or Green-GO talk app. The connection Mode is set to Search IP, The Password is set to the same as the bridgeport. Make sure the IP address is set to the same subnet as the bridge.

Internal vs External

In this scenario both the internal or external network of the bridge can be used.

Internal Example

To integrate Mobile devices with Green-GO talk into a system, A Wireless access-point can be added to the Green-GO Lan (Bridge internal connection) Mobile devices connected to this access-point in the same subnet as the Green-GO system will automatically discover available bridge ports and connect if the passwords match.

External Example

To integrate a remote device on another site, connected through a VPN sharing a subnet across the two sites. Connecting the "cross site LAN" to the external interface of the bridge. With an external IP in the same subnet as the "cross site LAN". The Remote device is able to automatically discover available bridge ports and connect using its password. This has the added benefit that the Local Green-GO traffic is separated from the traffic on the "cross site LAN" and vice versa.

Direct IP Connection

The Classic way to setup a connection to a bridge. This still can have a place in local but routed connections like a wifi link or between buildings on a campus. Internet (cloud) access is not needed.

Direct IP Connection Setup

When the bridge is setup right in the IT infrastructure and port forwarding the port connection needs to be setup

Group mode

  • Mode: Group bridge
  • Group: Select any group from the local config. note that the group on the remote site can be named different on a different config
  • Call, determine if sending and or receiving calls over the bridge connection is needed
  • Routing enabled/Don't Route. when routing is enabled the the bridge can act as proxy between other sites. When set to Don't Route audio coming from the bridge will not be send over another bridge connection again.
  • Connection
  • Active/Passive (port-forwarding needed or not)
  • Password: 8 characters needs to be identical on both sides
  • Port: the forwarded UDP port on the passive side. Identical on both sides
  • Remote IP: (only on active side) the IP address of the gateway/router on the passive side (
  • Backup: OFF
  • SndBuf: Default, 99% of the time good. in case of connection issues this can be set smaller or larger
  • RecvBuf: Auto, if bad audio is experienced due to long latency set to bigger, note that more latency between sites will be experienced

User mode

  • Mode: User
  • User: If set to Any, the user can be selected on the remote device. if a user is selected a connected device is forced to the selected user. for the IPhone app a user needs to be selected.
  • Connection - always passive
  • Password: 8 characters needs to be identical on both sides
  • Port: the forwarded UDP port on the passive side. Identical on both sides
  • SndBuf: Default, 99% of the time good. in case of connection issues this can be set smaller or larger
  • RecvBuf: Auto, if bad audio is experienced due to long latency set to bigger, note that more latency between sites will be experienced

Complete Group bridge example

This is an example of a Group bridge between 2 sites. On both sides the Green-GO network and the Local "internet LAN" are kept separate. On Site A the port forwarding is setup in the router.

Group example

Property Bridge Site A (passive) Bridge Site B (active)
internal network (dynamic) (dynamic)
Ip Address
external network
Ip Address
Mode Group bridge Group bridge
Group Toronto Berlin
Call enabled enabled
Route Don't route Don't route
Mode Passive Connection Active connection
Password PASW1234 PASW1234
Remote/local Port 27001 27001
Remote IP - 172.217. 22.14
SndBuff Default Default
RecvBuff Auto Auto

Complete User bridge example

This is an example of a User bridge between 2 sites. On side A the Green-GO network and the Local internet LAN are kept separate. On Site B the Device plugs directly into the internet LAN as Dhcp is available on the device the IP config for the device is set to dynamic. On Site A the port forwarding is setup in the router. As the person on side B can have different roles the user can be selected on the remote device by setting the user to Any in the bridge

User example

Property Remote Device (active) Bridge Site B (passive)
internal network (dynamic) (dynamic)
Ip Address
external network
Ip Address -
Netmask -
Gateway -
Mode User Access Remote connection
User Any Reporter 1
Password PASW1235 PASW1235
Remote/local Port 27002 27002
Remote IP -
SndBuff Default Default
RecvBuff Auto Auto

IPv6 support

Presently, Green-GO firmware does NOT provide support for IPv6. Consequently, complications may arise with remote connections. Please be aware of the following scenarios:

  • Green-GO talk apps on mobile devices that exclusively receive an IPv6 address from the telecom provider will be unable to establish a connection with a bridge.
  • ISP routers on the passive side, which possess only an IPv6 Public-facing IP, cannot be utilized to connect a remote device.
  • Remote devices cannot obtain an IPv6 address in an IPv6-only IT infrastructure, resulting in connectivity issues with the bridge.

Please take this into consideration when configuring your system.

Written by: Henk-Jan Blok, Timo Toups