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.

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.

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.

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.

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.

A separate LAN for internal and external¶

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.

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¶

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 0.0.0.0. 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

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.

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:

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.

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.

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} } }%%
sequenceDiagram
    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->cloud: 
    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->cloud: 
    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 greengoconnect.com. 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.

Examples¶

Search IP connection¶

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.

Connection port 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 (https://www.whatismyip.com/)
• 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.

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

Search IP¶